Performance counter – 4

Additional web counters  to monitor performance

ASP.NET -> Request Execution Time		Bear in mind that this is only the time it took to execute the mos recent request.
ASP.NET -> Requests Current		Total of waiting and executing requests.
ASP.NET -> Request Wait Time		If wait time is going up and CPU is low then opening up the threading options will probably help.  This could also indicate the need to additional hardware to hand the load.
ASP.NET -> Requests Queued
ASP.NET Apps -> Pipeline Instance Count	Make sure this is for the Web Service App	Only on thread at time can use a Pipelin instance.  So a sudden increase can indicate backend latency.
ASP.NET Apps -> Requests Executing	Make sure this is for the Web Service App
ASP.NET Apps -> Requests Total	Make sure this is for the Web Service App
ASP.NET Apps -> Requests/sec	Make sure this is for the Web Service App	How quickly are we handling requests?

Performance counter – 3

performance monitor for web server

Counter Name	Collection Notes	Comments
.NET CLR Loading :Bytes in Loader Heap	Make sure this for aspnet_wp	The number of bytes committed by the class loader across all AppDomains. This counter should reach a steady state. If this counter is continuously increasing, monitor the “Current Assemblies” counter. There may be too many assemblies loaded per AppDomain.
.NET CLR Memory: % Time in GC	Make sure this for aspnet_wp	The percentage of time spent performing the last garbage collection. An average value of 5% or less would be considered healthy, but spikes larger than this are not uncommon. Note that all threads are suspended during a garbage collection
.NET CLR Memory -> # Gen 0 Collections	Make sure this for aspnet_wp	These three GC counters provide insight on the efficiancy of the GC.  Basically Gen 0 should be the highest.  Gen 1 should be at least 1/2 of Gen 0’s count and usually more like 10%.  Gen 2 should be the lowest.  It should be about 1/2 of Gen 1 and the less the better.  As we move up through the generations GC operations are more expensive so we want to watch and use these to determine if we need to examine allocation patterns.
.NET CLR Memory -> # Gen 1 Collections	Make sure this for aspnet_wp
.NET CLR Memory -> # Gen 2 Collections	Make sure this for aspnet_wp
.NET CLR Memory -> # Bytes in all Heaps	Make sure this for aspnet_wp	The number of bytes that are allocated currently by .NET.  This should have peaks and valleys.  A steady climb can indicate a memory leak or memory usage issue.
.NET CLR Exceptions -> # of Exceps Thrown	Make sure this for aspnet_wp	Exceptions are a very expensive thing yet very powerful thing.  They can be very helpful but should be an “exceptional” occurance.  Essentially the could should be low and not constantly climbing.  If there is an exception that is occuring on every call to some function that function should be analyzed to add validation logic to avoid the exception if possible.  If it has been identified that there are too many exceptions a debugger should be used to track down the type of exception that is causing the problem.
ASP.NET: Requests Queued		The number of requests currently queued. When running on IIS 5.0, there is a queue between inetinfo and aspnet_wp, and there is one queue for each virtual directory.
ASP.NET: Worker Processes Running		The current number of aspnet_wp worker processes. For a short period of time, a new worker process and the worker process that is being replaced may coexist. Although rare, sometimes processes deadlock while they are exiting. If you suspect this, consider using a tool to monitor the number of instances of the worker process. Alternatively, the Memory\Available Mbytes performance counter can be used, since these hanging processes will consume memory.
ASP.NET: Application Restarts	If this counter is going up you should also monitor: .NET CLR Loading -> Total AppDomains and Current AppDomains.  If current is growing line with Total then you know that you have and issue where the AppDomain is not getting unloaded on Application Restart and this can cause a leak.	When the ASP.NET Application Restarts all of the assemblies have to be unloaded, reloaded, reJITed, and all of the application memory objects must be reloaded.  Restarts typicall occur when editing the Web.Config or some other change to application filies.  A restart every once in a while is not a problem, but if they happen frequently this can become a performance issue.
ASP.NET: Worker Process Restarts		This is related to the number of Application Restarts and has similar performance implications. However the cause is typically things like the process crashing. This can also occur when hitting memory, queue limit, or timeout thresholds.
Process: % Processor Time.	Make sure this for aspnet_wp	The percentage of time the threads of this process spend using the processors. Threshold: 70%. Values greater than this for extended periods of time indicate a need to purchase hardware or optimize your application.
Process:Thread Count	Make sure this for aspnet_wp	The number of threads active in this process. Thread count often increases when the load is too high.
Process -> Private Bytes	Make sure this for aspnet_wp	If the application is completely managed this should grow in parrellel to # Bytes in All Heaps.  If this counter is growing consitently and # Bytes in All Heaps is level that is an indication that there is an unmanaged mem leak.
Process -> Virtual Bytes	Make sure this for aspnet_wp	Most application run out of addressable memory before they run into any physical memory limitation so this counter is very imporant to monitor because if it goes above 1.2 GB the chances of an out of memory condition are VERY high.
Process -> Handle Count	Make sure this for aspnet_wp	The OS has a finite amount of handles for things like Files, Events and other OS objects so it is important in a web scenario to make sure that you are not leaking handles these.
Memory -> Available MBytes		Import when considering how often we are paging.  This count also can impact how frequently the GC needs to run
Web Service: Current Connections		A threshold for this counter is dependent upon many variables, such as the type of requests (ISAPI, CGI, static HTML, and so on), CPU utilization, and so on. A threshold should be developed through experience.
Web Service: Total Method Requests/sec		Used primarily as a metric for diagnosing performance issues. It can be interesting to compare this with “ASP.NET Applications\Requests/sec” and “Web Service\ISAPI Extension Requests/sec” in order to see the percentage of static pages served versus pages rendered by aspnet_isapi.dll.
Web Service: ISAPI Extension Requests/sec		Used primarily as a metric for diagnosing performance issues. It can be interesting to compare this with “ASP.NET Applications\Requests/sec” and “Web Service\Total Method Requests/sec.” Note that this includes requests to all ISAPI extensions, not just aspnet_isapi.dll.

Performance Counters – 2

Performance monitor for SQL Server

Counter Name	Collection Notes	Comments
SQLServer:Access Methods – Full Scans / sec		Value greater than 1 or 2 indicates that we are having table / Index page scans. We need to analyze how this can be avoided.
SQL Server:Cache Manager – Cache hit ratio		The ratio between the cache hits and misses. This counter is a good indicator of our caching mechanism in SQL Server. This value needs to be high in the system
SQL Server:Databases – Transactions/sec		This number indicates how active our SQL Server system is. A higher value indicates more activity is occurring
SQL Server:Databases – Log growths		The number of times the log files have been extended. If there is lot of activity in this counter we need to allocate static and large enough space for our log files.
SQL Server:General Statistics – User Connections		The number of users currently connected to the SQL Server.

Performance testing – 1

Generic performance monitors for both web app and db server

Counter Name:	Collection Notes	Comments:
Processor – %Processor Time		The percentage of time the processor spent executing a non-idle thread. This value is subtracted from the time the processor was idle 100 percent. This is an indicator to the overall CPU utilization in the system.
Processor – %Interrupt Time		The percentage of time the processor spent servicing hardware interrupts. This can be any activity on the server machine. This needs to be 0 while our testing process.
Processor – Processor Queue Length	Make sure to capture for all Processors on the machine	This counter indicates the number of threads that are waiting in the processor queue. It can be also interpreted as the number of threads that are waiting to be run by the processor. If this value is greater than the number of processor then we have aCPU bottleneck in the system
PhysicalDisk – Avg. Disk Queue Length		Average number of requests that waited for the read and write requests in the particular disk. A high value suggests we have a IO bottleneck.
Memory – Page Faults/sec		Total number of faulted pages handled by the processor per second. This value needs to be as small as possible
Memory – Pages/sec		The number of pages written to disk or from disk to resolve page faults. This would be the sum of page reads/sec and page writes/sec counter.

Performance Testing

Performance tests deal with how well a set of functions or operations work, rather than how they work as in feature tests. Whether a performance test passes or fails depends on whether the specific set of functions or operations deliver the functionality in a performing way. The performance release criteria of the product have to be validated with tests categorized as performance tests. 

 

Since the performance tests need to reveal the true performance nature of the product, the test code that needs to measure the performance needs to be clean and lean.  In other words, one needs to be careful not to introduce any overhead that is not related to the product’s true functionality.  Validation, error check need to be done in a way that should not affect the true performance measurement of the product.

 

Reporting on a performance test is far more demanding than from a feature test. A report on the performance results need to not only report on whether the performance tests pass or fail based on a specific set of criteria, but also need to have detailed information in order for developer or reader to digest how the performance characteristic is. The results analysis and data interpretation is of significant importance to a performance test.  This needs to be handled with great care.

 

Performance test need to be clear on:

1.)  What is the objective of the test? What for, why do you want to do it?

2.)  What are the key primitives/actions that the test is targeted to?

3.)  How is it related to release criteria/customer impact?

4.)  What are the performance metrics that are meaningful to this operation, e.g. latency, throughput?

5.)  What bottlenecks would be identified for the tests?

6.)  What is the clear context under which this test is conducted? Single user or multiple concurrent users?

7.)  Resource utilization: CPU, DiskI I/Os, memory consumption, network throughput/usage…

8.)  The environment parameters in which the results obtained? Large customer sets/data center?

What is the hardware used?