This is the second part of a three part series that addresses monitoring client access in an Exchange 2010 environment. It is meant to provide a good overall introduction into client access monitoring. This post will highlight Performance from an access and hardware perspective.
It’s one thing to know that you client access server is accessible, it’s another thing to know it is performing as expected. One of the key ways to monitor the Client Access Server role is by taking several performance counter endpoints into consideration.
Outlook Web App
MSExchange OWA-We can determine and monitor current user load by taking a couple of counters into consideration.
|MSExchange OWA\Current Unique Users|
|Shows the number of unique users currently logged on to Outlook Web Access. This value monitors the number of unique active user sessions, so that users are only removed from this counter after they log off or their session times out.|
|Shows the number of requests handled by Outlook Web Access per second.|
|MSExchange OWA\Average Response Time|
|Shows the average time (in milliseconds) that elapsed between the beginning and end of an OEH or ASPX request. Used to determine the latency that a client is experiencing.|
|MSExchange OWA\Average Search Time|
|Shows the average time that elapsed while waiting for a search to complete.|
RPC/HTTP Proxy-We can determine and monitor current Outlook anywhere usage and load.
|RPC/HTTP Proxy\Current Number of Incoming RPC over HTTP Connections|
|Shows the current number of front-end HTTP connections.|
|RPC/HTTP Proxy\Current Number of Unique Users|
|Shows the number of unique users currently connected to a back-end server via RPC/HTTP.|
|RPC/HTTP Proxy\RPC/HTTP Requests per Second|
|Shows the rate of RPC/HTTP requests sent to the back-end servers helpful in determining load.|
MSExchange ActiveSync-We can determine and monitor mobile connections and performance. These counters can help determine if problems with mobile device access are local to the Client Access server.
|Shows the number of HTTP requests that are received from the client via ASP.NET per second. Determines the current Exchange ActiveSync request rate.|
|Shows the number of HTTP requests that are received from the client via ASP.NET per second. Stats Only to determine current user load.|
|MSExchange ActiveSync\Average Request Time|
|Shows the average time that elapsed while waiting for a request to complete. Includes Ping Request Time, which can increase the general response time of this counter. Adding ping counters helps clarify where performance is being impacted. Determines the rate at which Availability service requests are occurring.|
Rpc Client Access
MSExchange RpcClientAccess-We can determine and monitor overall client access connectivity
|MSExchange RpcClientAccess\Active User Count|
|Active User Count is the number of unique users that have shown some activity in the last 2 minutes.|
|MSExchange RpcClientAccess\Connection Count|
|Connection Count is the total number of client connections maintained.|
|MSExchange RpcClientAccess\RPC Operations/sec|
|RPC Operations/sec is the rate at which RPC operations occur, per second.|
|MSExchange RpcClientAccess\User Count|
|User Count is the number of users that are connected to the service.|
MSExchange Availability Service-The Availability service in Exchange 2010 provides Microsoft Office Outlook clients resource checking availability. These counters help you to assess the client load and responsiveness of the service itself.
|MSExchange Availability Service\Availability Requests (sec)|
|Shows the number of requests serviced per second. The request can be only for free/busy or include suggestions. One request may contain multiple mailboxes. Determines the rate at which Availability service requests are occurring.|
|MSExchange Availability Service\Average Time to Process a Free Busy Request|
|Shows the average time to process a free/busy request in seconds. One request may contain multiple mailboxes. Free/busy responses do not have meeting suggestions.|
Address Book Service
MSExchangeAB –We can use the counters below to monitor address book service connections and performance.
|MSExchangeAB\NSPI Connections Current|
|NSPI Connections Current is the number of NSPI clients that are currently connected to the server.|
|MSExchangeAB\NSPI RPC Browse Requests Average Latency|
|Shows the average time, in ms, that Name Service Provider Interface (NSPI) browse requests took to complete during the sampling period.|
|MSExchangeAB\NSPI RPC Requests Average Latency|
|Shows the average time, in ms, that NSPI requests took to complete during the sampling period.|
Exchange Control Panel
MSExchange Control Panel –The counters below can help determine Control Panel load and performance.
|MSExchange Control Panel\Requests – Average Response Time|
|Requests – Average Response Time is the average time (in milliseconds) the Exchange Control Panel took to respond to a request during the sampling period.|
|MSExchange Control Panel\ASP.Net Request Failures/sec|
|ASP.Net Request Failures/sec is the number of failures per second detected by ASP.Net in the Exchange Control Panel.|
|MSExchange Control Panel\Inbound Proxy Requests/sec|
|Inbound Proxy Requests/sec is the number of requests received from a primary Client Access server per second.|
There are various additional counters associated with these objects that can provide valuable insight into overall Client Access performance. Thresholds vary per counter and will also vary on the environment being monitored. There are some generic recommended thresholds, but it is best to take a baseline performance metric during normal operations and use that to compare to subsequent measurements.
Of course both connectivity and access performance are subject to the performance of your underlying hardware. The obvious things that we need to consider to ensure system performance are processor and memory utilization as well as network saturation. These can be monitored by using standard windows Performance Monitor counters for the associated hardware components. See below for a few examples to keep an eye on.
|Processor (_Total)\% Processor Time||The average percentage of time that all processors are active. This counter is the primary indicator of average processor activity. This value is derived by calculating the percentage of time during the sample interval that all processors spent in executing their idle thread (which consumes cycles on a processor when no other threads are ready to run), and then subtracting the result from 100 percent.
This value should remain below 75%, if you’re constantly running above that the server is over utilized, check user load as you might need to add additional servers to the CAS array
|System\Processor Queue Length||The number of threads in the processor queue. Shows ready threads only, not threads that are running. Even multiprocessor computers have a single queue for processor time; thus, for multiprocessors, you need to divide this value by the number of processors servicing the workload. A sustained processor queue of less than two threads per processor is normally acceptable, depending upon the workload.|
|Memory \ %Committed Bytes in Use||% Committed Bytes In Use is the ratio of Memory \ Committed Bytes to the Memory \ Commit Limit. Committed memory is the physical memory in use for which space has been reserved in the paging file should it need to be written to disk. The commit limit is determined by the size of the paging file. If the paging file is enlarged, the commit limit increases, and the ratio is reduced). This counter displays the current percentage value only; it is not an average.|
|Network Interface\Bytes Total/sec.||This will tell you overall how much information is going in and out of the interface. Typically, you can use this to get a general feel, but will want to look at the Bytes Sent/sec and the Bytes Received/sec for a more exact detail of the type of traffic.|
Keeping an eye on these counters can help give you a better idea of your client access environments load and performance. Please check back next week for part three as we look into how you can use GSX Monitor to monitor, manage, measure and analyze client access connectivity and performance within your Exchange Server 2010 environment. If you missed part one: connectivity, you can view that here: Exchange 2010 Monitoring: Client Access (Part 1, Connectivity).