There are numerous tools and services available for interpreting Web site usage. If you want to do this work yourself, you can use your IIS logs to compile the information that you require.
The goal of performance testing is to plan for peak periods on the Web site. Generally, site operators consider peak to be three times their normal load. With this in mind, you should try to gather usage statistics from a period long enough that it includes periods that are as close to your peak usage as possible. After having done this, you can identify a peak period and use those numbers for your testing. Typically, a sample of a day is used.
To get pages per second, you might want to record a script using ACT. Then open the script and take out any redirects. In other words, leave in URLs like http://localhost/mysite/default.htm. But, on an ASP site, you would want to take out anything like http://localhost/mysite/. The reason for this is that this URL is simply a redirect and does not correspond to a page hit.
However, on an ASP.NET site, you would not want to have a URL like http://localhost/mysite/ right next to the URL http://localhost/mysite/default.htm. These two URLs are equivalent, and therefore one of them could be considered a redirect. Having done this, you can use your performance counters to calculate pages per second. Once you have warmed up the site by running the test for a few minutes before you start to record, ASP.NET (or ASP) requests per second will equal pages per second. This is a rough method, but it generally works well.
We have now completed our discussion of one of the main methods of performance testing a Web site: prototype modeling. This method involves running tests on hardware similar to the production environment and on applications that model your production code.
In summary, the way to use this method is to create a test environment as close to your production environment as possible. Then you would create your usage profile, simulate this profile using a stress tool, and determine the throughput of the profile in pages per second. Based on this, you can extrapolate the number of concurrent users that your site can support. You can use rules of thumb like 30 seconds per click per user, or you can use the statistics in your usage profile. Once you have all this information, you can take your throughput and divide it by the number of clicks for each user. For example, if your site renders 100 pages per second and your users click 1 page per second, then you could support 100 concurrent users.
We will now move on to the other popular strategy for performance testing: Transaction Cost Analysis (TCA).