| The following sections describe counters for profiling specific types of technologies. ASP.NET and Web Services ASP.NET and Web service applications are both served up by Microsoft Internet Information Services (IIS) and the ASP.NET ISAPI filter. They are both, after all, HTTP-based. As a result, you can treat a Web service like just another ASP.NET application. Granted, there might be other things you need to keep an eye out for, depending on the application, but this relationship should hold for most applications. Table D-2 lists the common application-specific ASP.NET performance counters. Table D-2. Application-Specific ASP.NET Performance Counters | Category | Counter | Description | | .NET CLR ASP.NET Applications | Requests /Sec | Indicates the current number of HTTP requests served per second by the ASP.NET worker process. This gives a general indication of how well your application is performing. Obviously more is always better, but this number is best used to produce relative measurements (such as when a feature addition affects the application's performance by increasing or decreasing the requests per second). | | .NET CLR ASP.NET Applications | Requests Executing | Shows how many requests are being executed concurrently by your application. If this number always stays high while your RPS stays low and your request queue grows, you might have a threading problem. (Check your context switches and thread locks.) Are you accessing a common resource that permits only mutually exclusive access? | | .NET CLR ASP.NET | Requests Queued | Are requests coming in too fast to be processed immediately? This counter will tell you. In a deployment situation, it will let you know that you need to add another machine to your farm to handle the incoming requests. In development, it might indicate that you're taking too long serving requests. Or, if there is processor time to spare, it might indicate that you need to tune ASP.NET to generate more threads to handle the incoming requests. | | .NET CLR ASP.NET Applications | Request Execution Time | Gives a definite indication of how long requests are taking. | | .NET CLR ASP.NET | Worker Process Restarts | Worker process restarts are generally not desirable, but they are periodically used to help ASP.NET recover from a bad state. You can tune ASP.NET's restart behavior in the Machine.config file. However, a worker process restart might mean that your application consumed too much memory or failed so severely that forcing a restart was ASP.NET's only way out. A worker process restart will also cause you to lose your session state information (unless you're using the Session State service). | SQL Database Applications Working with SQL applications can be challenging, mainly because your database will typically reside on a separate machine from your application's data layer. Therefore, the performance counters are divided into two sections, SQL Server and Data Layer, as described in Tables D-3 and D-4. Table D-3. SQL Server Performance Counters | Category | Counter | Description | | SQLServer:General Statistics | User Connections | This counter can give you a good idea of how efficiently your application is using connection pooling and whether you have any connection leaks. | | SQLServer:Databases | Transactions/sec | If you use transactions, this can be a good measure of how active your application is. | | SQLServer:SQL Statistics | SQL Compilations/sec | If this number is high (in the hundreds or thousands) and the machine is running low on processor time, you might want to consider moving your dynamic T-SQL statements into stored procedures. This will reduce the number of SQL compilations and reduce the overhead per request. | Table D-4. Data Layer Performance Counters | Category | Counter | Description | | .NET CLR Data | SqlClient: Current # pooled connections | This will definitely help you understand how well your pool is being utilized. By evaluating the behavior of this counter under varying load conditions, you can determine whether you have connection leaks. Use this in conjunction with the SQL Server User Connections counter to get a good handle on the pool usage. | | .NET CLR Data | SqlClient: Total # failed connections | If the connection pool is being exhausted by the number of incoming requests, you'll begin to see connection failures. This is another indicator you can use to adjust your pooling behavior. | Applications That Use Interop or Remoting Tracking the amount of Interop marshaling done by an application is an extremely important metric, as is tracking the remoting calls. As you'll recall from our discussion of chatty vs. chunky calls in Chapter 4 ”see page 148 ”you can use either of the performance counters described in Table D-5 to get an indication of how chatty your application might be. Table D-5. COM Interop and Remoting Performance Counters | Category | Counter | Description | | .NET CLR Interop | # of marshalling | On an application-by-application basis, you can evaluate how frequently your application is marshaling to and from the COM world. The ideal is to keep the amount of marshaling to a minimum. Remember the idea of chunky method calls from Chapter 4. If you're doing a lot of marshaling, consider whether you're doing as much work as possible. | | .NET CLR Remoting | Remote calls/sec | The ideal is to keep the number of remote calls to a minimum. Remember the idea of chunky method calls from Chapter 4. If you're doing a lot of remote calls, consider whether you're doing as much work as possible with each method invocation. | |
