Home arrow Web Services arrow Page 3 - ACT for Dummies

ACT for Dummies

If you are working with .Net for your web application and you would like to know how to test its performance using ACT, then this article is must read.

Author Info:
By: C. Prashanth
Rating: 4 stars4 stars4 stars4 stars4 stars / 10
March 24, 2003
  1. · ACT for Dummies
  2. · How to ACT
  3. · Analyzing the Results
  4. · Conclusion

print this article

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

ObjectPerformance CounterIndicates
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.
MemoryAvailable BytesAmount of memory available on the test client.
Network InterfaceBytes Total/secAmount of network traffic traveling to and from the test client.

General performance counters

Active Server PagesRequests QueuedThis should remain close to 0. If it exceeds the IIS queue length, "Server too Busy" errors result.
MemoryAvailable BytesThis 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.
MemoryPage Reads/secPage 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.
MemoryPool Paged Bytes and Pool Nonpaged BytesPools hold objects created and used by applications and the operating system. If the pools fill up, there might be a memory leak.
Network InterfaceBytes Total/secComparing 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 timeShows 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

ObjectPerformance CounterIndicates
ASP.NETRequest QueuedGives 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 ApplicationRequest/secGives 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 ApplicationErrors TotalGives 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.NETApplication Restarts, Worker process RestartsThese 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 ThrownThis 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.

blog comments powered by Disqus

- Dealing with Loose Coupling in a Service-Ori...
- Loose Coupling in a Service-Oriented Archite...
- Safety, Idempotence, and the Resource-Orient...
- The Resource-Oriented Architecture in Action
- Features of the Resource-Oriented Architectu...
- The Resource-Oriented Architecture
- Getting Started with Flex
- Automated Billing and Faxing for the Web
- An Introduction to Web Services
- The Foundations of Web Services: From Novice...
- Web Services Reengineering: Finishing Touches
- Fault Handling with Web Services
- Flow and Web Services
- Process Lifecycles and Web Services
- Business Processes and Web Services

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials