ACT for Dummies - Analyzing the Results
(Page 3 of 4 )
The Summary Reports shows you any major errors that prevented the test from producing reliable results. It also provides the most important information- 'The performance of the Web application'. In these reports, the following are the few sections to check out for:
Overview- This page provides the general performance for the test run, such as the requests per second that the Web server was able to handle, the duration of the test, and the total number of requests sent and number of errors occurred. Poorly-formed URLs, invalid server names or port numbers can cause connection problems and other network errors. Under periods of intense load, the Web server will often begin to reject a portion of the new connections clients attempt to create. Under heavy loads, the Time to Last Byte (TTLB) value will increase, often to the point where connection time-outs may occur for slower Web applications.
Response Code- Response codes should all be in the range of 200. Response codes in the range of 400 indicate client errors, while numbers in the range of 500 indicate server errors. For example, 404 response codes could be due to missing content on the Web server. The Request reports for each request made will contain the page responsible for the errors.
Performance Counters- Below is the list of important counters which needs to be monitored :
Performance counters on the Clients
| Object | Performance Counter | Indicates |
| Processor | % Processor Time/_Total | Processor use level on the test client. If the ACT client's processor use was above 90%, and the Web server's processor use was not high enough, then the ACT client may not have been capable of producing sufficient load during the test. If the Web server's processor use was too low, increase the number of simultaneous connections. |
| 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. |
General performance counters
| Object | Counter | Indicates |
| Active Server Pages | Requests Queued | This should remain close to 0. If it exceeds the IIS queue length, "Server too Busy" errors result. |
| 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 | Page Reads/sec | Page Reads/sec is the number of times the disk was read to resolve hard page faults. Sustained rates of 5 Page Reads/Sec probably indicates a memory shortage. |
| 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 might 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. |
| Physical Disk | % 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. |
| 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. |
Performance counters for ASP.NET
| Object | Performance Counter | Indicates |
| ASP.NET | Request Queued | Gives the number of requests waiting to be processed. When this number starts to increment linearly with respect to client load it means that one has reached the maximum limit of concurrent requests processed on the machine. The default maximum for requests queued is 5,000 but this can be changed via the machine.config file. |
| ASP.NET Application | Request/sec | Gives the current throughput of the application. Under constant load, this number should remain within a certain range, barring other server work (i.e. garbage collection, cache cleanup thread, external server tools, etc). |
| ASP.NET Application | Errors Total | Gives the errors in the application assuming that the web server isn’t the cause for these errors (web server causing errors are very rare). |
| ASP.NET | Application Restarts, Worker process Restarts | These two are useful because it tells how often ones application is getting reset on the server. An application restart can occur because of changes in configuration, bin assemblies and too many page changes. The worker process can be restarted due to fatal crash of it or due to controlled recycling. In either case, unexpected increases in these counters may point to unforeseen problems which need to be investigated. |
| .NET CLR Exceptions | # of Exceps Thrown | This is a CLR counter that tells the number of exceptions thrown within an application. Exceptions may lead to a performance hit. Exceptions don't always mean an error in your application in case of Response.ReDirect and Server.Transfer the ASP.NET page throws ThreadAbortException to quit the current page. |
Next: Conclusion >>
More Web Services Articles
More By C. Prashanth
/ 7 
