The .NET platform makes it fairly easy to write and deploy Web Services quickly. Being able to support both web-based (ASP.NET app) consumers and Windows application-based consumers from the same Web Service is a welcome efficiency. Finding tools to monitor your custom Web Services can be problematic and time consuming, but happily WMI provides classes to monitor them. Including .NET application workload information on top of basic IIS Server monitoring is essential to achieving accurate performance and capacity planning analysis, which lie at the heart of service assurance and forecasting both requirements and capital budgets.

What types of data will we want?

So here is how you build a good picture of workload and performance on .NET platforms. We will want our analysis to include both trend analysis and workload characterization. Trend analysis is simply looking at how the peaks are growing and estimating when resources will be exhausted. Workload Characterization includes examining the contribution of component workload processes during peak periods. Peak periods are important because they clearly show the relationship between capacity required to assure service and current resource consumption. First, define what needs to be included in the data collection to support the desired analysis, but it generally includes:

• Overall resource consumption on the platform
• Contributions of constituent workload processes (.NET apps) to global resource consumption

How much data will we need?

Next, we need to collect the data for our analysis. Usually, periods of data need to include sufficient samples and time in order to derive trends with high confidence. If you look at data over two weeks your trends will not have enough historical basis to be valid more than a few days into the future. A trend based on data collected over 12 months provides much higher confidence that a projection is valid several months out, or sufficient time to order new hardware. For trend analysis, it’s not so much the granularity of the samples that is important as that the data set includes all the normal variations seen in real workload processing plus the actual growth of resource consumption over time. In fact, an important best practice for maintaining the data set is to start summarizing trivial period measurements into fewer averaged samples. For example, summarize minutes into hours and hours into days. Without getting into all the statistical calculations specifically, it is sufficient for our analysis to reduce year-long analysis to days, weeks, and months, instead of minutes, hours, and days. We should strive to keep just enough data to meet our needs, without retaining data that is no longer statistically useful. In other words, we can get rid of a lot of fine granularity data (and storage space) that could be summarized into larger samples. For workload and performance analysis we do need data with finer granularity, but it need not cover long time periods, so long as it includes peak periods. So a sound strategy for data maintenance is to keep fine granularity data for a relatively short period, and start to summarize after 30 to 90 days.

What data should we collect?

Alright, now for what you want to collect for .NET platforms:

• Baseline Windows performance statistics
  • Win32_PerfRawData_PerfOS_System (Proc & Thread Count, Q-Len)
  • Win32_PerfRawData_PerfOS_Processor (% Processor Time)
  • Win32_PerfRawData_PerfOS_Memory (Free Mem & Page Faults)
  • Win32_PerfRawData_PerfDisk_LogicalDisk (Space, IO Ops and Q-Len)
• IIS performance Statistics (This will vary based on the type of applications)
  • Win32_PerfRawData_ASP_ActiveServerPages (Sessions, Requests, and Error)
  • Win32_PerfRawData_InetInfo_InternetInformationServicesGlobal (Cache Info)
  • Win32_PerfRawData_W3SVC_WebService (Total Connections and Throughput)
  • Win32_PerfRawData_NETFramework_NETCLRMemory (Heap and GC info)
• .NET Process Statistics
  • Win32_PerfRawData_W3SVC_WebService (Connections, Throughput , and Requests by application)
  • Win32_PerfRawData_ASPNET_2050727_ASPNETv2050727 (Requests and Sessions)
  • Win32_PerfRawData_ASPNET_2050727_ASPNETAppsv2050727 (Requests, Cache, Errors)

There are numerous .NET WMI Classes that can be easily viewed in the WBEMTEST interface, so if you have a very specialized application, it’s likely you will find the specific class that tracks what your application is doing.

Turning Data Into Useful Information

While collecting the data with WMI is straight forward, the same is not always true of interpreting the data. The win32_PerfRawData classes are just that, RAW. The statistics need to be ‘cooked’ (calculated) according to their data type. If you’d like to avoid this calculation, an easy way around it is to use the TypePerf command to get the data from PerfMon instead of WQL queries to WMI. WMI is a lot more efficient than launching numerous command processes running TypePerf, though. Once collected and cooked, store the data in a relational database; I use MySQL compliant MaxDB.

You will want to generate two types of representations of the data, Long Term Trends and Peak Profiles. Weekly or monthly periods of peak usage are great for profiling, depending on your business cycle processing. I like to build two graphs for my reports with both a trend over time and weekly or monthly profile. Here are sample queries (MySQL) for sorting the data from the ASPNETAppsv2050727 WMI Class:

Monthly Profile

select dayofmonth(aspr.sampletime) as SampleTime,
aspr.instance as ApplicationName,
round(avg(aspr.reqexectime),0) as AvgReqExecTime,
round(avg(aspr.reqwaittime),0) as AvgReqWaitTime,
round(avg(aspr.reqexecuting),0) as AvgReqExecuting,
round(avg(aspr.reqbytesintotal),0) as AvgReqBytesInTotal,
round(avg(aspr.reqbytesouttotal),0) as AvgReqBytesOutTotal
from aspdotnetv2_appsreq aspr
where ($TIME_CONDITION)
group by dayofmonth(aspr.sampletime), aspr.instance

Weekly Profile

select dayname(aspr.sampletime) as SampleTime,
aspr.instance as ApplicationName,
round(avg(aspr.reqexectime),0) as AvgReqExecTime,
round(avg(aspr.reqwaittime),0) as AvgReqWaitTime,
round(avg(aspr.reqexecuting),0) as AvgReqExecuting,
round(avg(aspr.reqbytesintotal),0) as AvgReqBytesInTotal,
round(avg(aspr.reqbytesouttotal),0) as AvgReqBytesOutTotal
from aspdotnetv2_appsreq aspr
where ($TIME_CONDITION)
group by dayname(aspr.sampletime), aspr.instance

To query for usage over time for trending, we simply eliminate the time functions in the statement, DayOfMonth and DayName. Also remove the aggregation of the variables so that

round(avg(aspr.reqexectime),0) as AvgReqExecTime

becomes much simpler as

aspr.reqexectime as ReqExecTime

Now that we have all the pieces to build our analysis reports. What are the burning questions that managers want answered in the reports?

• How well is the current platform supporting the load?
  • “Monitoring Service Levels & Performance Evaluation”
• How long will the current platform support Peak Usage?
  • “Capacity Planning“
• What does each application contribute to overall load?
  • “Workload Characterization“
• Should the applications be co-located?
  • “Workload Balancing”

With our data we can show the total load on the .NET platform. We can even go further to characterize the load that each .NET application contributes to the global activity. By examining the weekly and monthly profiles that show the relative activity of the applications we can characterize the workload sufficiently to perform workload balancing and understand peak usage constraints better. Extend the timeline and view the trend to forecast the point at which the current platform will find resources saturated. Now, this can be a bit time consuming to set up, so as usual I built a few custom .NET and Web Services solutions and reports for Longitude; if you’d like copies, just send me an email.