| What? | What for? | Where? | How? | |||||
| Performance Counter | Web | APP | DB | File | Context | Significance | Threshold | Tuning |
| Memory | ||||||||
| Memory\Available Mbytes | × | × | × | × | Bottlenecks or leaks | This indicates the amount of physical memory available to processes running on the computer. Note that this counter displays the last observed value only. It is not an average. | A consistent value of less than 20 to 25 percent of installed RAM is an indication of insufficient memory. | Increase RAM. |
| Memory\Pages/sec | × | × | × | × | Bottlenecks or leaks | This counter indicates the rate at which pages are read from or written to disk resolve hard page faults. | Sustained values higher than 20 indicate a bottleneck. | Increase RAM. |
| Memory\Pool Non-paged Bytes | × | × | × | × | Bottlenecks or leaks | If there is an increase of 10 percent or more from its value at system startup, a serious leak is potentially developing. | An increase of 10 percent or more from its value at system startup. | Restart Machine. |
| Memory\Cache Bytes | × | × | × | × | Bottlenecks or leaks | Monitors the size of cache under different load conditions. This counter displays the size of the static files cache. By default, this counter uses approximately 50 percent of available memory, but decreases if the available memory shrinks, which affects system performance. | No specific value. If performance degrades when the cache is large, consider adding RAM. If performance degrades when the cache is small, consider increasing the time interval during which objects remain in the cache before being flushed. | Increase RAM. |
| Memory\Cache Faults/sec | × | × | × | × | Bottlenecks or leaks. Cache bottlenecks are mainly a server problem. | This counter indicates how often the operating system look for data in the file system cache but fails to find it. The cache is independent of data location but is heavily dependent on data density within the set of pages. | No specific value as such. This value should be as low as possible. A high rate of cache faults can indicate insufficient memory or could also denote poorly localized data. | § Add Memory. § Dedicate a single computer. § Give the cache higher priority for space than the working sets of processes. § Localize your application's data references. |
| Network I/O | ||||||||
| Network Interface\Bytes Total/sec | × | × | × | × | Throughput | This counter indicates the rate at which bytes are sent and received over each Network Adapter. This counter helps us know whether the traffic at your adapter is saturated and if you need to add another Network Adapter. How quickly we can identify a problem depends on the type of network you have as well as whether you share bandwidth with other applications. | Sustained values of more than 80 percent of network bandwidth. | § Analyzing this counter would enable you to determine that you need to add extra items such as another NIC card. Note: this value is selected by instance (with the instance being your adapters). Note also that this counter assumes you are using TCP/IP with the SNMP service installed. |
| Network Interface\Packets/sec | × | × | × | × | Throughput | This counter indicates Packets/sec is the rate at which packets are sent and received on the network interface. | Should be less than NIC (Network Interface Cards) can handle. | |
| Disk I/O | ||||||||
| PhysicalDisk\% Disk Time\ Drive Letter | × | × | × | × | Bottleneck | This counter monitors the percentage of time that the disk is busy with read/write activity. | Value > 90% may indicate lack of RAM or a disk controller issue. | § Using a faster disk drive. § Moving some files to an additional disk or server. § Adding disks to a RAID array, if one is being used. |
| PhysicalDisk\Current Disk Queue Length\Drive Letter | × | × | × | × | Bottleneck | This counter shows how many read or write requests are waiting (for Disk access) to execute to the disk. | Generally if it is above 3 then we have an issue. Shortage of RAM will tend to beat on the disk. | |
| Processor | ||||||||
| Processor\%Processor Time\ _Total | × | × | × | × | Usage | This counter is the primary indicator of processor activity. High values may not necessarily be bad. However, if the other processor related counters are increasing linearly such as % Privileged Time or Processor Queue Length, high CPU utilization may be worth investigating. | Values > 90% indicates need for addition processing power. The average CPU utilization should always be below 80 percent. | § Replace the application or try to fix it by using the performance optimizing tools. § Upgrade your network or disk adapter cards. § Increase the processor clock speed. § Upgrade to a faster processor or add another processor. |
| System\Context Switches/sec | × | × | × | × | Bottlenecks | Context Switching happens when a higher priority thread preempts a lower priority thread that is currently running or when a high priority thread blocks. High levels of context switching can occur when many threads share the same priority level. This often indicates that there are too many threads competing for the processors on the system. If we donot see much processor utilization and very low level of context switching, it could indicate that threads are blocked. | If context switching rates exceed 20,000 per second per processor, then there is a constraint. | |
| System\ Processor Queue Length | × | × | × | × | Bottlenecks | If there are more tasks ready to run than there are processor, threads queue up. The processor queue is the collection of threads that are ready but not able to be executed by the processor because another active thread is currently executing. To cause less context switching, we could reduce the number of threads and queue more at the application level. | Generally if it is above 2 on averages then we have an issue. | |
| ASP.Net | ||||||||
| ASP.NET Applications\ Request / sec \ _Total | × | × | | | Throughput | The throughput of the ASP.Net application on the server. It is one of the primary indicators that help you measure the cost of deploying our system at the necessary capacity. | No absolute number. Determine trend over time by base lining. The performance test baselines are an average 6 requests/sec. | § Tune the thread pool using the formula for reducing contention. § Configure the memory limit. § Configure timeouts aggressively. § Evaluate configuring RequestQueue limit. § Disable tracing and debugging. § Disable session state if you do not use it. § Disable View State if you do not need it. § If you upload large files, consider maxRequestLength. § Consider Web gardens for scenarios that benefit from processor affinity. |
| ASP.NET\Requests Current | × | × | | | Throughput | The number of requests currently handled by the ASP.Net ISAPI. This includes those that are queued, executing, or waiting to be written to the client. ASP.Net begins to reject requests when this counter exceeds the requestQueueLimit defined in the processModel configuration section. | Should not exceed 5000. Note: If ASP.Net\Requests Current is greater than zero and no responses have been received from the ASP.Net worker process for a duration greater than the limit specified by | |
| ASP.NET Applications \Requests Timed Out | × | × | | | Throughput | The number of requests that have timed out. You need to investigate the cause of request timeouts. One possible reason is contention between various threads. | No specific value. To investigate further, we can debug and analyze the process using a run-time debugger such as WinDbg. | |
| ASP.NET\ Requests Wait Time | × | × | | | Queues | The number of milliseconds the most recent request was waiting in the named pipe queue between the IIS and the ASP.Net worker process. This does not include any time spent in the queue for a virtual directory hosting the web application. | 1,000 milliseconds. The average request should be close to zero milliseconds waiting in queue. | |
| .Net CLR | ||||||||
| .NET CLR Memory\ % Time in GC | × | × | | | Bottlenecks or leaks | This counter indicates the percentage of elapsed time spent performing a garbage collection since the last garbage collection cycle. The most common cause of a high value is making too many allocations which may be the caseif you are allocating on a per-request basis for ASP.Net applications. | This counter should average about 5 percent for most applications when the CPU is 70 percent busy, with occasional peaks. As the CPU load increases, so does the percentage of time spent performing garbage collection. Keep this in mind when you measure the CPU. | We need to study allocation profile for our application if this counter shows a higher value. |
| .NET CLR Memory\Large Object Heap Size | × | × | | | Bottlenecks or leaks | The large object heap size shows the amount of memory consumed by objects whose size is greater than 85 KB. The large object heap cannot be compacted after collection and may become heavily fragmented over a period of time. Note: Our design needs to enable efficient garbage collection, for example by correctly using the Dispose pattern and considering object lifetime. | No specific values. We should take attention and investigate our memory allocation profile if we see large numbers here. Note: The main CLR-related bottlenecks are caused by contention for resources, inefficient resource cleanup, misuse of the thread pool, and resource leaks. | CLR tuning is mostly achieved by designing and then optimizing your code to enable the CLR to perform its tasks efficiently. |
| SQL Server | ||||||||
| SQL Server: Access Methods : Page Splits/sec | | | × | | Usage | This counter indicates large number of page splits. Page splitting occurs when an index or data page becomes full, and then is split between the current page and a newly allocated page. While occasional page splitting is normal, excess page splitting can cause excessive disk I/O and contribute to slow performance. | <>. Number of page splits per second that occur as the result of overflowing index pages. | If number of page splits is high, consider increasing the fill factor of your indexes. |
| SQL Server: Buffer Manager: Buffer cache hit ratio | | | × | | Usage | This counter indicates how often SQL Server goes to the buffer, not the hard disk, to get data. The higher this ratio, the less often SQL Server has to go to the hard disk to fetch data, and performance overall is boosted. | Hit ratio Should be greater than 90%. | Stop and restart the SQL Server service. |
| SQL Server: Buffer Manager: Page Life Expectancy | | | × | | Usage or bottlenecks | This performance monitor counter tells you, on average, how long data pages are staying in the buffer. If this value gets below 300 seconds, this is a potential indication that your SQL Server could use more memory in order to boost performance. | Should not be less than 300 seconds. | Add Memory. |
| SQL Server: Locks: Lock Waits\sec | | | × | | Usage or queue | This counter reports how many times users waited to acquire a lock over the past second. | Should be 0 (zero) second. | Identify what specific transactions are causing the locking and take further steps. |
| SQL Server: SQL Statistics: Batch Requests/sec | | | × | | Bottlenecks | This counter measures the number of batch requests that SQL Server receives per second, and generally follows in step to how busy your server's CPUs are. | Generally speaking, over 1000 batch requests per second indicates a very busy SQL Server, and could mean that if you are not already experiencing a CPU bottleneck, that you may very well soon. | § Add hardware. § We may need to have two or more network cards, or go to a 1 Gbs network card. |
Vinay Jagtap
A hard core Technocrat with over a decade of extensive experience in heading complex test projects coupled with real time experience of project management and thought leadership. Extensive experience in Performance, Security and Automation Testing and development of automation frameworks and ability to setup and execute Global service centers and Center of Excellences for testing.
