Important Counters for Web Testing
During a test run, performance counters on the test client, and all Web servers should be monitored. Application Center Test will automatically monitor HTTP performance statistics during the test run, but performance counters must be explicitly configured before a test run.
Performance counter data is used to determine when a test client or Web server has reached its maximum CPU use. In cases where the performance bottleneck for the Web application is not the server CPU, performance counters will be the easiest way to determine where the bottleneck is occurring.
Some counters should be used in all tests (those shown in Bold type in the following lists), while others will only be helpful when trying to find less obvious sources of performance problems.
Performance counters on the ACT Clients
|Processor||% Processor Time/_Total||Processor use level on the test client.|
|Memory||Available Bytes||Amount of memory available on the test client.|
|Network Interface||Bytes Total/sec||Amount of network traffic traveling to and from the test client.|
Performance counters for Windows 2000 and IIS 5
Note that the following counters are for Microsoft Windows 2000, IIS 5, and Microsoft SQL Server 7.0. Other versions may use different counters.
Recording performance counters on the Web server will give information about what part of the web application is responsible for the performance decrease.
|Active Server Pages||Memory Allocated||The total amount of memory currently allocated by Active Server Pages. Compare this number to Memory:Available Bytes and Memory:Committed Bytes to determine what percentage ASP is using. A ratio of greater than 50% during the test would indicate a memory leak in a Server Side Object.|
|Active Server Pages||Request Errors/Sec||The number of errors per second, including connection errors, compile errors, and runtime errors. If this number is ever greater than 0, something is wrong with the test scripts, server configuration, or ASP scripts.|
|Active Server Pages||Requests Queued||This should remain close to 0. If it exceeds the IIS queue length, "Server too Busy" errors result.|
|Active Server Pages||Requests Rejected||If this number is often above 0, either the test load is too heavy or the server does not have sufficient resources.|
|Active Server Pages||Requests/Sec||ASP requests per second.|
|Internet Information Services Global||File Cache Flushes and File Cache Hits||These counters can be compared to see the ratio of hits to cache clean up. A flush occurs when a file is removed from the cache. These global counters provide some indication of the rate at which objects are being flushed from the cache. If flushes are occurring too slowly, memory is being wasted. You can modify this value by adjusting the ObjectCacheTTL, MemCacheSize, and MaxCacheFileSize registry settings. You can consult the Windows 2000 Resource Kit for more information.|
|Internet Information Services Global||File Cache Hits %||This displays the ratio of cache hits to total cache requests. It should be about 80% for sites with static pages.|
|Memory||Available Bytes||This is the amount of physical memory remaining and available for use. Each additional connection uses about 10 KB above the IIS base level of 2.5 MB.|
|Memory||Cache Bytes||Reveals the size of the cache used for static files. By default this is set to about 50% of available memory, but will decrease if the available memory decreases, thus decreasing system performance.|
|Memory||Page Faults/sec||This is the overall rate at which faulted pages are handled by the CPU. Page Faults/sec does not distinguish between soft and hard page faults, but they can be calculated. Memory: pages Input/sec is the number of pages read from disk to resolve hard page faults. Further, Memory: Page Reads/sec is the number of times the disk was read to resolve hard page faults. Compare these values against the Page Faults/sec to get a ratio. Sustained rates of 5 Page Reads/Sec probably indicate a memory shortage.|
|Memory||Pages/sec||If the server does not have enough memory to handle its workload, this number will be consistently high.|
|Memory||Pool Paged Bytes and Pool Nonpaged Bytes||Pools hold objects created and used by applications and the operating system. If the pools fill up, there may be a memory leak.|
|Network Interface||Bytes Total/sec||Comparing this value against the total available bandwidth should give a clear indication of a potential network bottleneck. As a general rule, try to keep the bytes/sec under 50% of the total available bandwidth.|
|Object||Threads||Threads are the basic executable entity that can execute instructions in a processor. If this number continues to rise over time, open the Process:Thread Count counter and see which instance is creating all of the threads.|
|PhysicalDisk||% Disk time||Shows the percentage of elapsed time that the disk is busy with read/write activity. If this counter is high and the processor and network bandwidth are not saturated, then there is likely a disk bottleneck. Run "diskperf -yD" from the Windows 2000 command line before logging this counter. A number consistently above 80% may indicate a memory leak. Make sure you add the 0 through x instances of this counter for multi-disk machines.|
|PhysicalDisk||Disk Queue Length||Shows the number of outstanding requests on the disk. Sustained queue lengths above 3 on one disk indicate a disk, memory, or SQL Server configuration problem.|
|Process||Private Bytes - _Total||Shows the current number of bytes that all instances have allocated that cannot be shared with other processes. Make sure you select the _Total instance from the list. Select whatever other instances you suspect may be using up memory.|
|Process||Private Bytes (inetinfo instance)||Private Bytes (inetinfo) is the current number of bytes the HTTP/ASP service has allocated that cannot be shared with other processes. If this number is consistently large, and growing, there is probably a leak in a Server Side Object. Compare with Process: Private Bytes (_Total).|
|Process||Thread Count (inetinfo instance)||The number of threads created by the Web server process.|
|Processor||% Processor Time (_Total instance)||This is the best counter for viewing processor saturation. Shows the amount of time spent processing threads by all CPUs. A number consistently above 90% on one or more processors indicates that the test is too intense for the hardware. Add the 0 through x instances of this counter for multi-processor servers.|
|Processor||Interrupts/sec||If the processor utilization is above 90 percent, and % Interrupt Time is greater than 15%, the processor is probably overburdened with interrupts.|
|Server||Bytes Total/sec||Shows network activity.|
|System||Processor Queue Length||This shows the number of threads waiting to be executed in the queue that is shared by all processors on the web server. A processor bottleneck can cause sustained values greater than 2.|
|System and Thread||Context Switches/sec, Context Switches/sec: dllhost (thread # instance), and Thread: Context Switches/sec: inetinfo (thread # instance)||These counters show how many costly context switches are occurring on the system as a whole, and within IIS 5.0 specifically.|
|Thread:||% Processor Time: InetInfo => Thread #||Displays how much processor time each thread of the InetInfo process is using.|
|Thread:||Context Switches/sec: InetInfo => Thread #||How many times the threads of the IIS service are switched onto and off of a processor.|
|Web Service||Bytes Total/sec||Shows the sum of bytes sent and received by the Web server.|
|Web Service||Current Anonymous Users||Shows the current number of connections to the service during an un-authenticated stress test.|
|Web Service||Current Non-Anonymous Users||The number of authenticated users currently connected to the HTTP Server.|
|Web Service||Not Found Errors||Shows the number of 404 response codes returned.|
Other performance counters
If the Web application uses Microsoft SQL Server or relies on any other applications to generate the response, then the performance counters for that program should also be monitored.
|SQL Server:General Statistics||Logins/sec||This is the count of the logins to SQL Server per second.|
|SQLServer:Cache Manager||Cache Hit Ratio (all instances)||Shows the hit rate that data is found in the cache. A number consistently less than 85% indicates a memory problem.|
|SQLServer:General Statistics||User Connections||Shows the number of active SQL users. Compare this number to the Active Server Pages:Requests/Sec counter to get an idea of how much the scripts are working the SQL Server. A large difference may indicate that the test script is not a valid stress of SQL Server.|
|SQL Server:Databases||Transactions/sec||The total number of transactions that have been started.|
|SQLServer:Locks||Lock Waits/sec||Shows the number of lock requests per second that force another process to wait until the current process is complete. If consistently greater than 0 it indicates transaction problems.|
- For information on adding a performance counter to the test, see Add and Configure Performance Counters.