posted 11-14-2001 12:19 PM         

I am new member here, but have been doing stress testing on assorted platforms for a few (5) years now.

I'm looking to "formalize" some standard for my team that stress tests our web applications. Currently for all tests we monitor (on IIS web server):

* processor (% processor time)
* memory (pool nonpaged bytes)
* memory (% committed bytes in use)
* active server pages (requests queued)
* active server pages (request wait time)

Can anyone think of any other counters that should always be logged?

Thanks much

posted 11-15-2001 06:48 AM         

What a great list. Can you elaborate on any of these items? For example, is there any disk (logical or physical) queue length metric that would signal problems? Or must it be read in conjunction with other metrics? And the IIS Global cache hit % - bigger is better?

Obviously I have much to learn about these resource metrics!

posted 11-15-2001 02:31 PM         

* Passed HTTP Connections
Number of successful HTTP connections established by all reported http_request commands.
* Failed HTTP Connections
Number of HTTP connection attempts that failed to establish a connection for all reported http_request commands.
* HTTP Sent Kbytes
Kilobytes of data sent by reported http_request and commands.
* HTTP Received Kbytes
Kilobytes of data received by reported http_nrecv and http_recv commands.
* Sent Kbytes/Connection
Kilobytes of data sent by reported http_request and commands per connection. Derived by dividing the kilobytes of data sent by the number of successfully established HTTP connections.
* Passed Connections/Min
Number of successful HTTP connections established per minute. Derived by dividing the number of successful HTTP connections by the active time.
* Avg Connect Setup Time
Average time, in milliseconds, required to establish a successful HTTP connection. Derived by dividing the total connection time for all recorded http_request commands by the number of successful connections.
* HTTP Sent Kbytes/Sec
Kilobytes of data sent per second. Derived by dividing the kilobytes of data sent by all recorded http_request and commands by the active time.
* HTTP Recv Kbytes/Sec
Kilobytes of data received per second. Derived by dividing the kilobytes of data received by all recorded http_nrecv and http_recv commands by the active time.
* Recv Kbytes/Connection
Kilobytes of data received by reported http_nrecv and http_recv commands per connection. Derived by dividing the kilobytes of data received by the number of successfully established HTTP connections.

AND we monitor IIS on (copied from our performance testing manual)

HTTP service performance counters
* Connections/sec
Specifies the number of connections to the HTTP server per second.
* Current ISAPI Extension Requests
Specifies the current number of ISAPI requests being processed by the server.
* Logon Requests
Specifies the total number of logon attempts that have been made by the HTTP server.
* Maximum Connection
Specifies the maximum number of simultaneous connections to the HTTP server.
* Not Found Errors
Specifies the total number of requests that failed due to a missing document.

Active Server Pages counters
The ASP object provides excellent counters to do detailed monitoring of your ASP application. The following points are particularly important:
* Errors-related counters
These should be near zero in value. Any errors-related counters that are significantly larger than zero should be further investigated before proceeding with troubleshooting.
* Errors During Script Runtime
* Errors From ASP Preprocessor
* Errors From Script Compilers
* Errors/Sec
* Requests executing
This is very important because it tells you whether your application is forced to be single-threaded or not. The default worker threads for executing ASP requests in IIS 4.0 is 10 (ProcessorThreadMax in the registry). If the ASP Requests Executing counter returns a value of "1", then your requests are definitely being serialized for some reason. Make sure Web Application debugging is not on because this will serialize your requests.
* Requests queued
If this number keeps increasing continuously, your ASP pages have blocked all threads for some reason and no threads are being released to service additional requests from the queue.
If the Requests Queued counter never increases and the processor(s) utilization is low, the site has more capacity than currently needed. If the Requests Queued counter moves up and down, and the processor(s) are running below 50 percent, this indicates that some requests are blocking, and therefore, an increase in the ASPProcessorThreadMax metabase entry may be in order.
The Requests Queued counter grows uncontrollably along with CPU utilization. Check custom or third-party components. A component may have failed, and ASP is waiting for a response from the component.
* The Requests Queued counter grows and CPU utilization increases to an unacceptable level. Check the connectivity to databases that ASP is calling. A slow network connection, a large query, or a slow back-end computer can cause blocking.
* Requests/Sec
* Requests Rejected
Requests not honored, this does not necessarily mean an error, the system could have been too busy.
* Sessions total
This is the total number of sessions since the Web service was started. You may want to stop and restart the Web service before a test run to accurately monitor the total sessions being created for a specific test run. Make sure that while your script is running this number keeps gradually increasing until it reaches the desired total.

And last but not least:
Global IIS performance counters
* Cache Flushes
Specifies how often a cached memory region expired due to changes in IIS files or a directory tree.
* Cache Hits %
Specifies the hit ratio of all cache requests.
* Cache Used
Specifies the total number of bytes in use (file handles, IIS specific objects, and so on) in the cache.
* Cached File Handles
Total number of file handles contained within the cache.

posted 11-16-2001 12:30 PM         

CPU usage
Memory usage
Swap/Paging File usage
I/O Waits

on solaris I get this all using vmstat and iostat.

posted 02-08-2002 07:30 AM         

Once again, thanks for the information. As you can see, I'm new to this site but I hope to contribute as much as I can as I increase my knowledge/experience.

posted 02-08-2002 05:53 PM         

Memory and CPU used by the server / DB
Cache metrics (hit rates should be high >80%)
Concurrent locks (low)

If you can nail a problem down to the DB aspect you should get a DBA to investigate potential causes: poor schema design, poor query design are more likely culprits, even though (cynically) I think most DBAs will want to write everything as stored procedures.

FWIW

Phil

posted 02-12-2002 07:48 AM         

------------------
Simple minds, Simple thoughts!