Dot net performance monitoring

1. ASP.net Performance Monitoring and
Analysis – Part 1
Kranthi Paidi
1

2. Foreword
2
 All the material in this power point presentation is a
consolidation of what ever I read and learnt on the
internet, many technical forums, Microsoft’s MSDN and
books.
 All the credit goes to the following:
 MSDN technet website (http://technet.microsoft.com/en-
us/ms376608.aspx)
 Improving .net application performance and Scalability
(http://www.amazon.com/Improving-Application-
Performance-Scalability-
Practices/dp/0735618518/ref=sr_1_1?ie=UTF8&qid=13514494
92&sr=8-
1&keywords=improving+.net+application+performance+and+s
calability+patterns+and+practices)

3. Part 1 – Session Goals
3
 Understand general set of performance counters for all
Microsoft (some of them are technology agnostic) web
applications
 Understand specific set of performance counters for CLR
and ASP.net framework
 Understand the impact of trends in various performance
counters
 A basic idea on different ways to instrument and measure
the performance of .NET applications
 A basic understanding of View State

4. Performance Objectives
4
Performance objectives for any web application include the following:
 Response time or latency
 Throughput
 Resource utilization

5. Response Time or Latency
5
Latency measured at the server.
This is the time taken by the server to complete the execution of a request. This does
not take into account the client-to-server latency, which includes additional time for
the request and response to cross the network.
Latency measured at the client.
The latency measured at the client includes the request queue, the time taken by the
server to complete the execution of the request, and the network latency. We can
measure this latency in various ways. Two common approaches are to measure the
time taken by the first byte to reach the client (time to first byte, or TTFB) or the time
taken by the last byte of the response to reach the client (time to last byte, or TTLB).
Generally, We should test this using various network bandwidths between the client
and the server.

6. Throughput
6
Throughput is the number of requests that can be successfully served by Our
application per unit time. It can vary depending on the load (number of users) applied
to the server. Throughput is usually measured in terms of requests per second. In
some systems, throughput may go down when there are many concurrent users. In
other systems, throughput remains constant under pressure but latency begins to
suffer, perhaps due to queuing. Other systems have some balance between maximum
throughput and overall latency under stress.

7. Resource Utilization
7
Resource Utilization
We identify resource utilization costs in terms of server and network resources.
The primary resources are the following:
 CPU
 Memory
 Disk I/O
 Network I/O
We can identify the resource cost on a per-operation basis. Operations might include
browsing a product catalog, adding items to a shopping cart, or placing an order. We
can measure resource costs for a given user load or We can average resource costs
when the application is tested using a given workload profile.

8. Metrics Matter
8
Measuring involves collecting data during the various stages of our application’s
development life cycle. We might need to collect data during prototyping, application
development, performance testing, and tuning, and in a production environment. The
following tools and techniques help us to collect data:
 System and platform metrics
 Network monitoring tools
 Profiling tools
 Tools for analyzing log files
 Application instrumentation

9. System and Platform Metrics
9
System Monitor.
This is a standard component of the Windows operating system. We can use it to
monitor performance objects and counters and instances of various hardware and
software components.
Microsoft Operations Manager (MOM) (System Center 2012)
We can install MOM agents on individual servers that collect data and send it a
centralized MOM server. The data is stored in the MOM database, which can be a
dedicated SQL Server or the Microsoft SQL Server 2000 Desktop Engine (MSDE)
version of Microsoft SQL Server. MOM is suitable for collecting large amounts of data
over a long period of time.
(http://technet.microsoft.com/en-us/library/hh205987.aspx)
Stress tools such as LoadRunner or VSTS
We can use tools such as LR to simulate clients and collect data during the duration of
a test.

10. Network Monitoring Tools
10
Internet Protocol Security (IPSec) monitor.
We can use IPSec monitor to confirm whether our secured communications are
successful. In this way we can monitor any possible pattern of security-related or
authentication-related failures.
Network Monitor (NetMon).
We use NetMon to monitor the network traffic. We can use it to capture packets sent
between client and server computers. It provides valuable timing information as well
as packet size, network utilization, addressing, and routing information and many
other statistics that We can use to analyze system performance.

11. Profiling Tools
11
CLR Profiler
This allows us to create a memory allocation profile for our application so we can see
how much allocation occurs, where it occurs, and how efficient the garbage collector
is within our application. By using the various profile views, We can obtain many
useful details about the execution, allocation, and memory consumption of our
application.
SQL Profiler
This profiling tool is installed with SQL Server. We can use it to identify slow and
inefficient queries, deadlocks, timeouts, recompilations, errors, and exceptions for any
database interactions.
SQL Query Analyzer.
This tool is also installed with SQL Server. We can use it to analyze the execution plans
for SQL queries and stored procedures. This is mostly used in conjunction with the SQL
Profiler.

12. Log Files
12
Analyzing log files is an important activity when tuning or troubleshooting our live
application. Log files can provide usage statistics for various modules of the
application, a profile of the users accessing our application, errors and exceptions,
together with other diagnostics that can help identify performance issues and their
possible cause.
We can analyze various logs including Internet Information Services (IIS) logs, SQL
Server logs, Windows event logs, and custom application logs. We can use various
third-party tools to analyze and extract details from these log files.
Examples of log analyzers:
Logparser
Google Analytics
Omniture

13. Application Instrumentation
13
In addition to the preceding tools, We can instrument our code for capturing
application-specific information. This form of information is much more fine-grained
than that provided by standard system performance counters. It is also a great way to
capture metrics around specific application scenarios.
For example, instrumentation enables us to measure how long it takes to add an item
to a shopping cart, or how long it takes to validate a credit card number.
Instrumentation is the process of adding code to our application to generate events to
allow us to monitor application health and performance. The events are generally
logged to an appropriate event source and can be monitored by suitable monitoring
tools such as MOM. An event is a notification of some action.
Instrumentation allows us to perform various tasks:
Profile applications
Profiling enables us to identify how long a particular method or operation takes to run
and how efficient it is in terms of CPU and memory resource usage.

14. Application Instrumentation - Options
14
Collect custom data.
This might include custom performance counters that we use to monitor application-
specific activity, such as how long it takes to place an order.
Trace code
This allows us to understand the application code path and all the methods run for a
particular use case.
We have several options:
 Event Tracing for Windows (ETW)
 Window Management Instrumentation (WMI)
 Custom performance counters
 Enterprise Instrumentation Framework (EIF)
 Trace and Debug classes

15. Application Instrumentation – Decision Making
15
What do We want to accomplish with instrumentation?
There are various goals for instrumentation. For example, if we need only debugging
and tracing features, we might use these features mostly in a test environment where
performance is not an issue. But if we plan to log the business actions performed by
each user, this is very important from a performance point of view and needs to be
considered at design time. If we need to trace and log activity, we need to opt for a
tool that lets us specify various levels of instrumentation through a configuration file
How frequently do We need to log events?
Frequency of logging is one of the most important factors that helps We decide the
right choice of the instrumentation tool for We. For example, the event log is suitable
only for very low-frequency events, whereas a custom log file or ETW is more suitable
for high-frequency logging. The custom performance counters are best for long-term
trending such as week-long stress tests.
Is our instrumentation configurable?
In a real-life scenario for a typical application, we might want to instrument it so the
data collected is helpful in various application stages, such as development
(debugging/tracing), system testing, tuning, and capacity planning.

16. Application Instrumentation - when and what
16
Based on the preceding considerations, the usage scenarios for the various options are
as follows.
Event Tracing for Windows (ETW)
ETW is suitable for logging high-frequency events such as errors, warnings or audits.
The frequency of logging can be in hundred of thousands of events each second in a
running application. This is ideal for server applications that log the business actions
performed by the users. The amount of logging done may be high, depending on the
number of concurrent users connected to the server.
Windows Management Instrumentation (WMI)
Windows Management Instrumentation is the core management technology built into
the Windows operating system. WMI supports a very wide range of management tools
that lets We analyze the data collected for Our application. Logging to a WMI sink is
more expensive than other sinks, so We should generally do so only for critical and
high-visibility events such as a system driver failure.

17. Application Instrumentation - when and what
17
Enterprise Instrumentation Framework (EIF)
EIF permits .NET applications to be instrumented to publish a broad spectrum
of information such as errors, warnings, audits, diagnostic events, and
business specific events. We can configure which events we generate and
where the events go, to the Windows Event Log service or SQL Server, for
example. EIF encapsulates the functionality of ETW, the Event Log service, and
WMI. EIF is suitable for large enterprise applications where We need various
logging levels in Our application across the tiers. EIF also provides We a
configuration file where We can turn on or turn off the switch for logging of a
particular counter. EIF also has an important feature of request tracing that
enables We to trace business processes or application services by following
an execution path for an application spanning multiple physical tiers.EIF is
available as a free download from the Microsoft Download Center at the
Microsoft Enterprise Instrumentation Framework page at
http://www.microsoft.com/downloads/details.aspx?FamilyId=80DF04BC-
267D-4919-8BB4-1F84B7EB1368&displaylang=en

18. Application Instrumentation - when and what
18
Trace and Debug Classes
The Trace and Debug classes allow us to add functionality in our application mostly for
debugging and tracing purposes. The code added using the Debug class is relevant for
debug builds of the application. We can print the debugging information and check
logic for assertions for various regular expressions in our code. We can write the
debug information by registering a particular listener.
Example:
public static void Main(string[] args){
Debug.Listeners.Add(new TextWriterTraceListener(Console.Out));
Debug.AutoFlush = true;
Debug.WriteLine("Entering Main");
Debug.WriteLine("Exiting Main");
}

19. System Resources
19
When we need to measure how many system resources our application consumes, we
need to pay particular attention to the following:
Processor
Processor utilization, context switches, interrupts and so on.
Memory
Amount of available memory, virtual memory, and cache utilization.
Network
Percent of the available bandwidth being utilized, network bottlenecks.
Disk I/O
Amount of read and write disk activity. I/O bottlenecks occur if read
and write operations begin to queue.

20. Processor
20
To measure processor utilization and context switching, we can use the following
counters:
Processor% Processor Time
Threshold: The general figure for the threshold limit for processors is 85 percent.
Significance: This counter is the primary indicator of processor activity. High values
many not necessarily be bad. However, if the other processor-related counters are
increasing linearly such as % Privileged Time or Processor Queue Length, high CPU
utilization may be worth investigating.
Processor% Privileged Time
Threshold: A figure that is consistently over 75 percent indicates a bottleneck.
Significance: This counter indicates the percentage of time a thread runs in privileged
mode. When Our application calls operating system functions (for example to perform
file or network I/O or to allocate memory), these operating system functions are
executed in privileged mode.

21. Processor
21
Processor% Interrupt Time
Threshold: Depends on processor.
Significance: This counter indicates the percentage of time the processor spends
receiving and servicing hardware interrupts. This value is an indirect indicator of the
activity of devices that generate interrupts, such as network adapters. A dramatic
increase in this counter indicates potential hardware problems.
SystemProcessor Queue Length
Threshold: An average value consistently higher than 2 indicates a bottleneck.
Significance: If there are more tasks ready to run than there are processors, threads
queue up. The processor queue is the collection of threads that are ready but not able
to be executed by the processor because another active thread is currently executing.
A sustained or recurring queue of more than two threads is a clear indication of a
processor bottleneck. We can use this counter in conjunction with the Processor%
Processor Time counter to determine if our application can benefit from more CPUs.
In a multiprocessor computer, divide the Processor Queue Length (PQL) value by the
number of processors servicing the workload.

22. Processor
22
If the CPU is very busy (90 percent and higher utilization) and the PQL average is
consistently higher than 2 per processor, we may have a processor bottleneck that
could benefit from additional CPUs. Or, we could reduce the number of threads and
queue more at the application level. This will cause less context switching, and less
context switching is good for reducing CPU load. The common reason for a PQL of 2 or
higher with low CPU utilization is that requests for processor time arrive randomly and
threads demand irregular amounts of time from the processor. This means that the
processor is not a bottleneck but that it is our threading logic that needs to be
improved.

23. Processor
23
SystemContext Switches/sec
Threshold: As a general rule, context switching rates of less than 5,000 per second per
processor are not worth worrying about. If context switching rates exceed 15,000 per
second per processor, then there is a constraint. Significance: Context switching
happens when a higher priority thread preempts a lower priority thread that is
currently running or when a high priority thread blocks. High levels of context
switching can occur when many threads share the same priority level. This often
indicates that there are too many threads competing for the processors on the system.
If We do not see much processor utilization and we see very low levels of context
switching, it could indicate that threads are blocked.

24. Memory
24
MemoryAvailable Mbytes
Threshold: A consistent value of less than 20 to 25 percent of installed RAM is an
indication of insufficient memory.
Significance: This indicates the amount of physical memory available to processes
running on the computer. Note that this counter displays the last observed value only.
It is not an average.
MemoryPage Reads/sec
Threshold: Sustained values of more than five indicate a large number of page faults
for read requests.
Significance: This counter indicates that the working set of our process is too large for
the physical memory and that it is paging to disk. It shows the number of read
operations, without regard to the number of pages retrieved in each operation. Higher
values indicate a memory bottleneck. If a low rate of page-read operations coincides
with high values for Physical Disk% Disk Time and Physical DiskAvg. Disk Queue
Length, there could be a disk bottleneck. If an increase in queue length is not
accompanied by a decrease in the pages-read rate, a memory shortage exists.

25. Memory
25
MemoryPages/sec
Threshold: Sustained values higher than five indicate a bottleneck.
Significance: This counter indicates the rate at which pages are read from or written to
disk to resolve hard page faults. Multiply the values of the Physical DiskAvg. Disk
sec/Transfer and MemoryPages/sec counters. If the product of these counters
exceeds 0.1, paging is taking more than 10 percent of disk access time, which indicates
that we need more RAM.
MemoryPool Nonpaged Bytes
Threshold: Watch the value of MemoryPool Nonpaged Bytes for an increase of 10
percent or more from its value at system startup.
Significance: If there is an increase of 10 percent or more from its value at startup, a
serious leak is potentially developing.

26. Memory
26
ServerPool Nonpaged Failures
Threshold: Regular nonzero values indicate a bottleneck.
Significance: This counter indicates the number of times allocations from the
nonpaged pool have failed. It indicates that the computer’s physical memory is too
small. The nonpaged pool contains pages from a process’s virtual address space that
are not to be swapped out to the page file on disk, such as a process’ kernel object
table. The availability of the nonpaged pool determines how many processes, threads,
and other such objects can be created. When allocations from the nonpaged pool fail,
this can be due to a memory leak in a process, particularly if processor usage has not
increased accordingly.
ServerPool Paged Failures
Threshold: No specific value.
Significance: This counter indicates the number of times allocations from the paged
pool have failed. This counter indicates that the computer’s physical memory or page
file is too small.

27. Memory
27
ServerPool Nonpaged Peak
Threshold: No specific value.
Significance: This is the maximum number of bytes in the nonpaged pool that the
server has had in use at any one point. It indicates how much physical memory the
computer should have. Because the nonpaged pool must be resident, and because
there has to be some memory left over for other operations, we might quadruple it to
get the actual physical memory we should have for the system.
MemoryCache Bytes
Threshold: No specific value.
Significance: Monitors the size of cache under different load conditions. This counter
displays the size of the static files cache. By default, this counter uses approximately
50 percent of available memory, but decreases if the available memory shrinks, which
affects system performance.

28. Memory
28
MemoryCache Faults/sec
Threshold: No specific value.
Significance: This counter indicates how often the operating system looks for data in
the file system cache but fails to find it. This value should be as low as possible. The
cache is independent of data location but is heavily dependent on data density within
the set of pages. A high rate of cache faults can indicate insufficient memory or could
also denote poorly localized data.
CacheMDL Read Hits %
Threshold: The higher this value, the better the performance of the file system cache.
Values should preferably be as close to 100 percent as possible. Significance: This
counter provides the percentage of Memory Descriptor List (MDL) Read requests to
the file system cache, where the cache returns the object directly rather than
requiring a read from the hard disk.

29. Disk I/O
29
PhysicalDiskAvg. Disk Queue Length
Threshold: Should not be higher than the number of spindles plus two. Significance:
This counter indicates the average number of both read and writes requests that were
queued for the selected disk during the sample interval.
PhysicalDiskAvg. Disk Read Queue Length
Threshold: Should be less than two.
Significance: This counter indicates the average number of read requests that were
queued for the selected disk during the sample interval.
PhysicalDiskAvg. Disk Write Queue Length
Threshold: Should be less than two.
Significance: This counter indicates the average number of write requests that were
queued for the selected disk during the sample interval.

30. Disk I/O
30
PhysicalDiskAvg. Disk sec/Transfer
Threshold: Should not be more than 18 milliseconds.
Significance: This counter indicates the time, in seconds, of the average disk transfer.
This may indicate a large amount of disk fragmentation, slow disks, or disk failures.
Multiply the values of the Physical DiskAvg. Disk sec/Transfer and
MemoryPages/sec counters. If the product of these counters exceeds 0.1, paging is
taking more than 10 percent of disk access time, so we need more RAM.

31. Network I/O
31
Network InterfaceBytes Total/sec
Threshold: Sustained values of more than 80 percent of network bandwidth.
Significance: This counter indicates the rate at which bytes are sent and received over
each network adapter. This counter helps us know whether the traffic at our network
adapter is saturated and if we need to add another network adapter. How quickly we
can identify a problem depends on the type of network we have as well as whether
we share bandwidth with other applications.
ServerBytes Total/sec
Threshold: Value should not be more than 50 percent of network capacity.
Significance: This counter indicates the number of bytes sent and received over the
network. Higher values indicate network bandwidth as the bottleneck. If the sum of
Bytes Total/sec for all servers is roughly equal to the maximum transfer rates of our
network, We may need to segment the network.

32. .NET Framework Technologies
32
The .NET Framework provides a series of performance counters, which we can
monitor using System Monitor and other monitoring tools. To measure other aspects
of .NET application performance, we need to add instrumentation to our applications.

33. CLR and Managed Code
33
What to Measure
When measuring the processes running under CLR some of the key points to look for
are as follows:
Memory
Measure managed and unmanaged memory consumption.
Working set
Measure the overall size of Our application’s working set.
Exceptions
Measure the effect of exceptions on performance.
Contention
Measure the effect of contention on performance.
Threading
Measure the efficiency of threading operations.
Code access security
Measure the effect of code access security checks on performance.

34. CLR Memory
34
ProcessPrivate Bytes
Threshold: The threshold depends on our application and on settings in the Machine
config file. The default for ASP.NET is 60 percent available physical RAM or 800 MB,
whichever is the minimum. Note that .NET Framework 1.1 supports 1,800 MB as the
upper bound instead of 800 MB if We add a /3GB switch in Our Boot.ini file. This is
because the .NET Framework is able to support 3 GB virtual address space instead of
the 2 GB for the earlier versions.
Significance: This counter indicates the current number of bytes allocated to this
process that cannot be shared with other processes. This counter is used for
identifying memory leaks.

35. CLR Memory
35
.NET CLR Memory% Time in GC
Threshold: This counter should average about 5 percent for most applications when
the CPU is 70 percent busy, with occasional peaks. As the CPU load increases, so does
the percentage of time spent performing garbage collection. Keep this in mind when
we measure the CPU.
Significance: This counter indicates the percentage of elapsed time spent performing a
garbage collection since the last garbage collection cycle. The most common cause of
a high value is making too many allocations, which may be the case if we are allocating
on a per-request basis for ASP.NET applications. we need to study the allocation
profile for Our application if this counter shows a higher value.
Private Bytes - # Bytes in all Heaps
This is the number of bytes allocated for unmanaged objects. This counter reflects the
memory usage by managed resources.

36. CLR Memory
36
.NET CLR Memory# Bytes in all Heaps
Threshold: No specific value.
Significance: This counter is the sum of four other counters — Gen 0 Heap Size, Gen 1
Heap Size, Gen 2 Heap Size, and Large Object Heap Size. The value of this counter will
always be less than the value of ProcessPrivate Bytes, which also includes the native
memory allocated for the process by the operating system.
.NET CLR Memory# Gen 0 Collections
Threshold: No specific value.
Significance: This counter indicates the number of times the generation 0 objects are
garbage-collected from the start of the application. Objects that survive the collection
are promoted to Generation 1. We can observe the memory allocation pattern of Our
application by plotting the values of this counter over time.

37. CLR Memory
37
.NET CLR Memory# Gen 1 Collections
Threshold: One-tenth the value of # Gen 0 Collections.
Significance: This counter indicates the number of times the generation 1 objects are
garbage-collected from the start of the application.
.NET CLR Memory# Gen 2 Collections
Threshold: One-tenth the value of # Gen 1 Collections.
Significance: This counter indicates the number of times the generation 2 objects are
garbage-collected from the start of the application. The generation 2 heap is the
costliest to maintain for an application. Whenever there is a generation 2 collection, it
suspends all the application threads. We should profile the allocation pattern for Our
application and minimize the objects in generation 2 heap.

38. CLR Memory
38
.NET CLR Memory# of Pinned Objects
Threshold: No specific value.
Significance: When .NET-based applications use unmanaged code, these objects are
pinned in memory. That is, they cannot move around because the pointers to them
would become invalid. These can be measured by this counter. We can also pin objects
explicitly in managed code, such as reusable buffers used for I/O calls. Too many
pinned objects affect the performance of the garbage collector because they restrict
its ability to move objects and organize memory efficiently.
.NET CLR MemoryLarge Object Heap Size
Threshold: No specific values. Significance: The large object heap size shows the
amount of memory consumed by objects whose size is greater than 85 KB. If the
difference between # Bytes in All Heaps and Large Object Heap Size is small, most of
the memory is being used up by large objects. The large object heap cannot be
compacted after collection and may become heavily fragmented over a period of time.
We should investigate Our memory allocation profile if We see large numbers here.

39. Working Set
39
ProcessWorking Set
Threshold: No specific value.
Significance: The working set is the set of memory pages currently loaded in RAM. If
the system has sufficient memory, it can maintain enough space in the working set so
that it does not need to perform the disk operations. However, if there is insufficient
memory, the system tries to reduce the working set by taking away the memory from
the processes which results in an increase in page faults. When the rate of page faults
rises, the system tries to increase the working set of the process. If We observe wide
fluctuations in the working set, it might indicate a memory shortage. Higher values in
the working set may also be due to multiple assemblies in our application. We can
improve the working set by using assemblies shared in the global assembly cache.

40. Exceptions
40
.NET CLR Exceptions# of Exceps Thrown / sec
Threshold: This counter value should be less than 5 percent of Request/sec for the
ASP.NET application. If We see more than 1 request in 20 throw an exception, we
should pay closer attention to it. Significance: This counter indicates the total number
of exceptions generated per second in managed code. Exceptions are very costly and
can severely degrade our application performance. We should investigate our code for
application logic that uses exceptions for normal processing behavior.
Response.Redirect, Server.Transfer, and Response.End all cause a
ThreadAbortException in ASP.NET applications.

41. Contention
41
.NET CLR LocksAndThreadsContention Rate / sec
Threshold: No specific value.
Significance: This counter displays the rate at which the runtime attempts to acquire a
managed lock but without a success. Sustained nonzero values may be a cause of
concern. We may want to run dedicated tests for a particular piece of code to identify
the contention rate for the particular code path.
NET CLR LocksAndThreadsCurrent Queue Length
Threshold: No specific value.
Significance: This counter displays the last recorded number of threads currently
waiting to acquire a managed lock in an application. We may want to run dedicated
tests for a particular piece of code to identify the average queue length for the
particular code path. This helps We identify inefficient synchronization mechanisms.

42. Threading
42
.NET CLR LocksAndThreads# of current physical Threads
Threshold: No specific value.
Significance: This counter indicates the number of native operating system threads
currently owned by the CLR that act as underlying threads for .NET thread objects.
This gives us the idea of how many threads are actually spawned by our application.
This counter can be monitored along with SystemContext Switches/sec. A high rate
of context switches almost certainly means that we have spawned a higher than
optimal number of threads for our process. If we want to analyze which threads are
causing the context switches, We can analyze the ThreadContext Swtiches/sec
counter for all threads in a process and then make a dump of the process stack to
identify the actual threads by comparing the thread IDs from the test data with the
information available from the dump.

43. Threading
43
Thread% Processor Time
Threshold: No specific value.
Significance: This counter gives us the idea as to which thread is actually taking the
maximum processor time. If we see idle CPU and low throughput, threads could be
waiting or deadlocked. We can take a stack dump of the process and compare the
thread IDs from test data with the dump information to identify threads that are
waiting or blocked.
ThreadContext Switches/sec
Threshold: No specific value.
Significance: The counter needs to be investigated when the SystemContext
Switches/sec counter shows a high value. The counter helps in identifying which
threads are actually causing the high context switching rates.
ThreadThread State
Threshold: The counter tells the state of a particular thread at a given instance.
Significance: We need to monitor this counter when we fear that a particular thread is
consuming most of the processor resources.

44. Code Access Security
44
.NET CLR SecurityTotal RunTime Checks
Threshold: No specific value.
Significance: This counter displays the total number of runtime code access security
checks performed since the start of the application. This counter used together with
the Stack Walk Depth counter is indicative of the performance penalty that our code
incurs for security checks.
.NET CLR SecurityStack Walk Depth
Threshold: No specific value.
Significance: This counter displays the depth of the stack during that last runtime code
access security check. This counter is not an average. It just displays the last observed
value.

45. ASP.net
45
To effectively determine ASP.NET performance, We need to measure the following:
Throughput. This includes the number of requests executed per second and
throughput related bottlenecks, such as the number of requests waiting to be
executed and the number of requests being rejected.
Cost of throughput. This includes the cost of processor, memory, disk I/O, and
network utilization.
Queues. This includes the queue levels for the worker process and for each virtual
directory hosting a .NET Web application.
Response time and latency. The response time is measured at the client as the
amount of time between the initial request and the response to the client (first byte
or last byte). Latency generally includes server execution time and the time taken for
the request and response to be sent across the network.

46. ASP.net
46
Cache utilization. This includes the ratio of cache hits to cache misses. It needs to be
seen in larger context because the virtual memory utilization may affect the cache
performance.
Errors and exceptions. This includes numbers of errors and exceptions generated.
Sessions. We need to be able to determine the optimum value for session timeout
and the cost of storing session data locally versus remotely. We also need to
determine the session size for a single user.
Loading. This includes the number of assemblies and application domains loaded, and
the amount of committed virtual memory consumed by the application.
View state size. This includes the amount of view state per page.
Page size. This includes the size of individual pages.
Page cost. This includes the processing effort required to serve pages.
Worker process restarts. This includes the number of times the ASP.NET worker
process recycles.

47. ASP.net counters mapped
47

48. ASP.net Throughput
48
To measure ASP.NET throughput, use the following counters:
ASP.NET ApplicationsRequests/Sec
Threshold: Depends on Our business requirements.
Significance: The throughput of the ASP.NET application on the server. It is one the
primary indicators that help We measure the cost of deploying Our system at the
necessary capacity.
Web ServiceISAPI Extension Requests/sec
Threshold: Depends on Our business requirements. Significance: The rate of ISAPI
extension requests that are simultaneously being processed by the Web service. This
counter is not affected by the ASP.NET worker process restart count, although the
ASP.NET ApplicationsRequests/Sec counter is.
To measure the throughput cost in terms of the amount of system resources that our
requests consume, we need to measure CPU utilization, memory consumption, and
the amount of disk and network I/O. This also helps in measuring the cost of the
hardware needed to achieve a given level of performance

49. ASP.net – Throughput – Requests
49
ASP.NETRequests Current
Threshold: No specific value.
Significance: The number of requests currently handled by the ASP.NET ISAPI. This
includes those that are queued, executing, or waiting to be written to the client.
ASP.NET begins to reject requests when this counter exceeds the requestQueueLimit
defined in the processModel configuration section. If ASP.NETRequests Current is
greater than zero and no responses have been received from the ASP.NET worker
process for a duration greater than the limit specified by <processModel
responseDeadlockInterval=/>, the process is terminated and a new process is started.
ASP.NET ApplicationsRequests Executing
Threshold: No specific value. Significance: The number of requests currently executing.
This counter is incremented when the HttpRuntime begins to process the request and
is decremented after the HttpRuntime finishes the request.

50. ASP.net – Throughput – Requests
50
ASP.NET Applications Requests Timed Out
Threshold: No specific value.
Significance: The number of requests that have timed out. We need to investigate the
cause of request timeouts. One possible reason is contention between various
threads. A good instrumentation strategy helps capture the problem in the log. To
investigate further, We can debug and analyze the process using a run-time debugger
such as WinDbg

51. ASP.net – Throughput – Queues
51
ASP.NET Requests Queued
Threshold: No specific value.
Significance: The number of requests currently queued. Queued requests indicate a
shortage of I/O threads in IIS 5.0. In IIS 6.0, this indicates a shortage of worker threads.
Requests are rejected when ASP.NETRequests Current exceeds the
requestQueueLimit (default = 5000) attribute for <processModel> element defined in
the Machine.config file. This can happen when the server is under very heavy load.
The queue between IIS and ASP.NET is a named pipe through which the request is sent
from one process to the other. In IIS 5.0, this queue is between the IIS process
(Inetinfo.exe) and the ASP.NET worker process (Aspnet_wp.exe.) In addition to the
worker process queue there are separate queues for each virtual directory (application
domain.) When running in IIS 6.0, there is a queue where requests are posted to the
managed thread pool from native code. There is also a queue for each virtual
directory. We should investigate the ASP.NET ApplicationsRequests In Application
Queue and ASP.NETRequests Queued to investigate performance issues.

52. ASP.net – Throughput – Queues
52
ASP.NET Applications Requests In Application Queue
Threshold: No specific value.
Significance: There is a separate queue that is maintained for each virtual directory.
The limit for this queue is defined by the appRequestQueueLimit attribute for
<httpRunTime> element in Machine.config. When the queue limit is reached the
request is rejected with a “Server too busy” error.
ASP.NET Requests Rejected
Threshold: No specific value.
Significance: The number of requests rejected because the request queue was full.
ASP.NET worker process starts rejecting requests when ASP.NETRequests Current
exceeds the requestQueueLimit defined in the processModel configuration section.
The default value for requestQueueLimit is 5000.

53. ASP.net – Throughput – Queues
53
ASP.NET Requests Wait Time
Threshold: 1,000 milliseconds. The average request should be close to zero
milliseconds waiting in queue.
Significance: The number of milliseconds the most recent request was waiting in the
named pipe queue between the IIS and the ASP.NET worker process. This does not
include any time spent in the queue for a virtual directory hosting the Web
application.

54. ASP.net - Latency
54
ASP.NETRequest Execution Time
Threshold: The value is based on our business requirements.
Significance: This is the number of milliseconds taken to execute the last request. The
execution time begins when the HttpContext for the request is created, and stops
before the response is sent to IIS. Assuming that user code does not call
HttpResponse.Flush, this implies that execution time stops before sending any bytes
to IIS, or to the client.

55. ASP.net - Cache Utilization
55
ASP.NET ApplicationsCache Total Entries
Threshold: No specific value.
Significance: The current number of entries in the cache which includes both user and
internal entries. ASP.NET uses the cache to store objects that are expensive to create,
including configuration objects and preserved assembly entries.
ASP.NET ApplicationsCache Total Hit Ratio
Threshold: With sufficient RAM, We should normally record a high (greater than 80
percent) cache hit ratio. Significance: This counter shows the ratio for the total
number of internal and user hits on the cache.
ASP.NET ApplicationsCache Total Turnover Rate
Threshold: No specific value.
Significance: The number of additions and removals to and from the cache per second
(both user and internal.) A high turnover rate indicates that items are being quickly
added and removed, which can impact performance.

56. ASP.net - Cache Utilization
56
ASP.NET ApplicationsCache API Hit Ratio
Threshold: No specific value.
Significance: Ratio of cache hits to misses of objects called from user code. A low ratio
can indicate inefficient use of caching techniques.
ASP.NET ApplicationsCache API Turnover Rate
Threshold: No specific value.
Significance: The number of additions and removals to and from the output cache per
second. A high turnover rate indicates that items are being quickly added and
removed, which can impact performance.

57. ASP.net - Cache Utilization
57
ASP.NET ApplicationsOutput Cache Hit Ratio
Threshold: No specific value.
Significance: The total hit-to-miss ratio of output cache requests.
ASP.NET ApplicationsOutput Cache Turnover Rate Threshold: No specific value.
Significance: The number of additions and removals to the output cache per second. A
high turnover rate indicates that items are being quickly added and removed, which
can impact performance.
ASP.NET ApplicationsOutput Cache Entries
Threshold: No specific value.
Significance: The number of entries in the output cache. We need to measure the
ASP.NET ApplicationsOutput Cache Hit Ratio counter to verify the hit rate to the
cache entries. If the hit rate is low, We need to identify the cache entries and
reconsider Our caching mechanism.

58. ASP.net Errors and Exceptions
58
ASP.NET Applications Errors Total/sec
Threshold: No specific value.
Significance: The total number of exceptions generated during preprocessing, parsing,
compilation, and run-time processing of a request. A high value can severely affect
Our application performance. This may render all other results invalid.
ASP.NET Applications Errors During Execution
Threshold: No specific value. Significance: The total number of errors that have
occurred during the processing of requests.
ASP.NET Applications Errors Unhandled During Execution/sec Threshold: No specific
value. Significance: The total number of unhandled exceptions per second at run time.

59. ASP.net Sessions
59
To measure session performance, We need to be able to determine the optimum
value for session timeout, and the cost of storing session state in process and out of
process.
Determining an Optimum Value for Session Timeout Setting an optimum value for
session timeout is important because sessions continue to consume server resources
even if the user is no longer browsing the site. If we fail to optimize session timeouts,
this can cause increased memory consumption.

60. ASP.net Sessions
60
To determine the optimum session timeout
 Identify the average session length for an average user based on the workload
model for our application.
 Set the session duration in IIS for Our Web site to a value slightly greater than the
average session length. The optimum setting is a balance between conserving
resources and maintaining the users session.
 Identify the metrics we need to monitor during load testing
 Run load tests with the simultaneous number of users set to the value identified for
our workload model. The duration of the test should be more than the value
configured for the session timeout in IIS.
 Repeat the load test with the same number of simultaneous users each time. For
each of the iterations, increase the value for the session timeout by a small
amount.
 For each of the iterations, We should observe the time interval where there is an
overlap of existing users who have completed their work but who still have an
active session on the server and a new set of users who have active sessions
increases. We should observe increased memory consumption.

61. ASP.net Sessions
61
 As soon as the sessions for the old set of users time out, memory consumption is
reduced. The height of the spikes in memory utilization depends on the amount of
data being stored in the session store on a per-user basis.
 Continue to increase the timeout until the spikes tend to smooth out and stabilize.
 Set Our session state to be as small as possible while still avoiding the memory
utilization spikes.
 Set a value for the session timeout that is well above this limit.

62. ASP.net Loading
62
.NET CLR Loading Current appdomains
Threshold: The value should be same as number of Web applications plus one.
The additional one is the default application domain loaded by the ASP.NET worker
process. Significance: The current number of application domains loaded in the
process.
.NET CLR Loading Current Assemblies
Threshold: No specific value.
Significance: The current number of assemblies loaded in the process. ASP.NET Web
pages (.aspx files) and user controls (.ascx files) are “batch compiled” by default, which
typically results in one to three assemblies, depending on the number of
dependencies. Excessive memory consumption may be caused by an unusually high
number of loaded assemblies. We should try to minimize the number of Web pages
and user controls without compromising the efficiency of workflow. Assemblies
cannot be unloaded from an application domain. To prevent excessive memory
consumption, the application domain is unloaded when the number of recompilations
(.aspx, .ascx, .asax) exceeds the limit specified by
<compilationnumRecompilesBeforeAppRestart=/>.

63. ASP.net Loading
63
.NET CLR Loading Bytes in Loader Heap
Threshold: No specific value.
Significance: This counter displays the current size (in bytes) of committed memory
across all application domains. Committed memory is the physical memory for which
space has been reserved in the paging file on disk.

64. ViewState
64
View state can constitute a significant portion of Our Web page output, particularly if
We are using large controls such as the DataGrid or a tree control. It is important to
measure the size of view state because this can have a big impact on the size of the
overall response and on the response time. We can measure view state by enabling
page level tracing. To enable tracing for a page, add the Trace attribute and set its
value to true as shown in the following code. <%@ Page Language="C#" Trace="True"
%>
View state is used primarily by server controls to retain state only on pages that post
data back to themselves. The information is passed to the client and read back in a
specific hidden variable called _VIEWSTATE. ASP.NET makes it easy to store any types
that are serializable in view state. However, this capability can easily be misused and
performance reduced. View state is an unnecessary overhead for pages that do not
need it. As the view state grows larger. it affects performance in the following ways:
 Increased CPU cycles are required to serialize and to deserialize the view state.
 Pages take longer to download because they are larger.
 Very large view state can impact the efficiency of garbage collection.

65. ViewState
65
Transmitting a huge amount of view state can significantly affect application
performance. The change in performance becomes more marked when our Web
clients use slow, dial-up connections. Consider testing for different bandwidth
conditions when We work with view state. Optimize the way our application uses view
state by following these recommendations:
 Disable view state if We do not need it.
 Minimize the number of objects We store in view state.
 Determine the size of Our view state.
View state is turned on in ASP.NET by default. Disable view state if We do not need it.
For example, We might not need view state because Our page is output-only or
because We explicitly reload data for each request

66. ViewState
66
We do not need view state when the following conditions are true:
Our page does not post back. If the page does not post information back to itself, if
the page is only used for output, and if the page does not rely on response processing,
We do not need view state.
We do not handle server control events. If our server controls do not handle events,
and if our server controls have no dynamic or data bound property values, or they are
set in code on every request, we do not need view state.
We repopulate controls with every page refresh. If we ignore old data, and if we
repopulate the server control each time the page is refreshed, we do not need view
state.

67. ViewState
67
There are several ways to disable view state at various levels:
To disable view state for all applications on a Web server, configure the <pages>
element in the Machine.config file as follows.
<pages enableViewState="false" />
This approach allows us to selectively enable view state just for those pages that need
it by using the EnableViewState attribute of the @ Page directive. To disable view
state for a single page, use the @ Page directive as follows.
<%@ Page EnableViewState="false" %>
To disable view state for a single control on a page, set the EnableViewState property
of the control to false, as shown in the following code fragment.
//programatically
yourControl.EnableViewState = false;
//something
<asp:datagrid EnableViewState="false" runat= "server" />

68. ViewState
68
Minimize the Number of Objects We Store In View State
As We increase the number of objects We put into view state, the size of our view
state dictionary grows, and the processing time required to serialize and to deserialize
the objects increases.
Use the following guidelines when We put objects into view state:
View state is optimized for serializing basic types such as strings, integers, and
Booleans, and objects such as arrays, ArrayLists, and Hashtables if they contain these
basic types.
When We want to store a type which is not listed previously, ASP.NET internally tries
to use the associated type converter. If it cannot find one, it uses the relatively
expensive binary serializer.
The size of the object is directly proportional to the size of the view state. Avoid
storing large objects

69. ViewState
69
Determine the Size of Our View State
By enabling tracing for the page, We can monitor the view state size for each control.
The view state size for each control appears in the leftmost column in the control tree
section of the trace output. Use this information as a guide to determine if there are
any controls that We can reduce the amount of view state for or if there are controls
that We can disable view state for.

70. Questions?
70
 Q&A

71. Thank You
71