NProf and ACT, Your Performance Assistants
By Klaus Salchner

---

Introduction
Take a trip down memory lane and recall the projects you have been involved in the last five years. Now give yourself a minute and list the three requirements your team missed, or think about the three things everyone wished you had spent more time on. This is an interesting question that, perhaps surprisingly, typically has similar answers across the industry. My answers would be Performance, Scalability, and Security followed very closely with Interoperability and Maintainability. If you did a market survey I am sure you would get similar answers from many development teams.

Time-to-market and features are not the only selling points. I work for an Enterprise Software Development company which is selling products to large and mid-sized enterprises. After we sell our product to the LOB (Line of Business) folks we next need to get past the IT hurdle. The questions the IT folks ask us are: how well does your product perform, how easy is it to scale your application to my growing user population, which security standards do you comply with, how easy is it to integrate your product with the rest of my IT eco system, and how expensive is it to maintain your product. These questions all target one area, how good are the "enterprise characteristics" of the product. If you want to continue selling products they better be darn good.

This article concentrates on how to improve the performance of your ASP.NET applications through the use of two tools: NProf and Microsoft's Application Center Test (ACT). We'll start with a high-level discussion on quantitatively measuring performance, and then dive into using NProf and ACT.

Treat Performance as a Feature
In my years of experience I have learned to treat performance and any other enterprise characteristic as a feature. Clearly state the goal and provision resources and time to be assigned against it. Furthermore, it is just as important that you quantitatively define the goals for performance. That is, stay away from defining an acceptable level of performance as having the application "responding quickly," or "has fast load times, even over a slow internet connection." You can't measure such subjective metrics as these, and engineers are like scientists, they want to measure it or it is meaningless. How do you measure whether the application is slow? You can put the application on a PII 400MHz and access it with two users and it might be lightning fast but use a Xeon 2GHz with two thousand users and the application is crawling along.

Your requirements need to state how many concurrent users your application needs to support on what hardware and what is the maximum allowed response time to the user. If the hardware requirements are unknown then it needs to be a deliverable by the development team. I visualize performance as a four-legged stool. If you are going to change one of the stool legs, you will likely have to change at least one of the other legs as well if you want the stool to remain standing. The four performance "legs" are:

• Response time,
• The end-user's hardware,
• The number of concurrent users, and
• The software or programming logic you are about to create

For example, imagine that you wanted to reduce the response time from ten seconds to five. You can accomplish this by reducing the number of concurrent users you need to support, or by adding hardware, or maybe by tuning your application to make it faster. Or it can be a combination of any of these.

A Closer Look at Number of Concurrent Users
Determining the number of concurrent users your system can expect is part mathematics, and part guesswork. Oftentimes, you'll know, or have a good idea, of the total number of potential users that you need to support; for example, if you are developing an intranet application for your company and there are 4,000 employees in your company, then there are 4,000 potential users.

Next, define how many of these users will likely use the application on a given day. Let's say your application is a time tracking sheet that is used only by about 25% of the users every day. This means you have 1,000 users per day. Next you define how long a day is for your company. If you have employees around the world then it is 24 hours. If you have employees on the West and East coasts of the US then it is something like 14 hours (take an eleven hour day which takes into consideration that some users start early and some stay late plus a three hour time difference you need to consider). The last thing you need to know is how long are users staying in the application, the session length. A time tracking application is likely not used more than 15 minutes a day. (Of course, you need to talk to your LOB folks or customer to find out and firm up this data.)

Armed with the above data, you can plug the numbers into the following formulas to determine your estimated number of concurrent users:

The "supported users per hour" calculates given in an hour how many slots to you have to serve users. In our example a user typically uses the system for 15 minutes so we end up with four slots per hour the system can use to serve users. This formula indicates that your application, on average, needs to support 18 concurrent users. Every application has peak usage, of course. Email systems, for example, have peak usage in the morning when everyone comes in and checks his/her emails. For other applications it might be in the late afternoon before employees leave for the day. Find out from your LOB folks or customer what this peak usage is.

When calculating the peak usage numbers, I typically assume that peak usage rates are 300% higher than average usage rates, meaning I multiply the average concurrent usage number by three to get the estimated peak usage number. In our sample that would come out to 54 concurrent users at peak time. After all of these calculations, I now know that I need to tune my application and hardware to support 54 concurrent users.

Making Concurrent Users an Easily Measurable Number
Typically the number of concurrent users is hard to measure for engineers. Engineers don't deal in terms of how many users will use the system, or the average number of users per hour. Rather, the metrics engineers work with include how many requests/sec the site will expect, and the maximum response time for the application. Given the requests per second and how long the average user will be using the application, an engineer can calculate the number of concurrent users.

We already defined how long users will use the application - in our example 15 minutes per session. But that does not mean that in these 15 minutes users will be constantly requesting new pages from your application. Users will click on a link or button, wait for the page to render in the browser, then read or scan the information on the page before clicking on another link or button. Industry standards claim that it should not take longer then five to ten seconds for your page to process and render in the browser and that users need about five to fifteen seconds to understand what is displayed on a page before they click the next link or button. Taking this information you can say that a user will issue a page request every ten to 25 seconds. Plugging these numbers into the formulas below, you can compute the concurrent user metric.

This is a measurable number which every engineer can measure using Microsoft's Application Center Test (ACT) or any of the other performance testing tools on the market. Given the concurrent number of users you can use back of the envelope calculations to determine what hardware your application will need to run on in order to meet the required performance criteria. We'll look at these pieces in Part 2 of this article.

Read Part 2!

Windows Internet Technology | ASP.NET [1.x] [2.0] | ASPMessageboard.com | ASPFAQs.com | Advertise | Feedback | Author an Article