take you to get through the intersectionwhere the accident occurred) is increas-ing, but you aren’t even moving. You arenot doing anything except standing still.It is not until three of the cars in front of you have moved that you can even think about moving. At this point, your traveltime is extremely long and you start tocrawl through the intersection. This alsoexplains why when you are in car number50, by the time you pass through theintersection, you have no idea what hap-pened and why you were stuck in trafficfor so long to begin with.So what does being stuck in traffic haveto do with the performance of your appli-cation? Plenty. They are both governedby basic queuing theory. Your applicationtakes requests; if the requests come infaster than they can be processed, theapplication will start to queue them up.That’s when the properties of queues andqueuing theory take over to explain thebehavior (or non-behavior) of your sys-tem. The principles of queuing theory arebeyond the scope of this article.
Understanding YourSystem and Creating aTransaction/UserProfile
So what does all this have to do with vir-tual users? Alot. Before you can begin tocreate scripts to be executed by the virtu-al users, you need a basic understandingof your system. If you understand thehardware architecture (NTserver, UNIXserver, load balancing, firewalls, separatedatabase server, number of CPUs andmemory, etc.) of your system and theimplementation (use of proxies, indexingin the database, load balancing algo-rithms, etc.) then you can assess whereprobable bottlenecks will occur and startyour performance testing in these areas.For example, if you know that your appli-cation will be asked to perform a lot of queries, but you don’t have a lot of mem-ory in your application server, the firstscripts that you write may just be queriesto the database. On the other hand, if youknow that certain processes in your appli-cation are CPU intensive, you may wantto create scripts that kick off theseprocesses and then try and perform othertasks while the CPU is busy.Before you create the scripts to test yourperformance, you also need to understandhow your users will actually use the sys-tem. What are typical scenarios users per-form? If you already have a live Web site,using a tool like WebTrends
will pro-vide you with useful user profile infor-mation. If you aren’t sure how users willuse your application, then you need tomake some guesses based upon theirbehaviors in similar environments. JohnMusa has written many articles andbooks on the subject of creating opera-tional profiles. Operational profiles areextremely useful in helping to analyze theprobable transactions to your application.If you are also trying to determine themaximum load that your Web site willneed to support, it is often useful to visityour competitors’Web sites. They willoften boast of their traffic (especially if they are selling ad time on their Website). We have found Web sites that boastthat they received 200 million hits in thelast 30 days. That gives you a good start-ing place from which to measure.Assuming a linear distribution of those200 million hits (note that a linear distri-bution is extremely unlikely, but it’s astart), then the 200,000,000/ 30 days =6666667 hits/day = 277778 hits/hour =4630 hits/sec. While the traffic to someweb sites may be indeed be linear over aparticular period of time (8AM-8PM), anexponential, or Poisson distribution maybe more realistic.Creating the scripts involves defining ascenario, or transaction, that your userwill execute. Ascenario may be com-prised of one or more transactions and atransaction may invoke one or more hits.For example, one transaction may bedefined as loading the home page.Actually executing this transaction maygenerate 1-50 hits. (We have seen homepages that load so many GIF files thatthey literally account for 75 hits.) Next,you need to assess how many times thisscenario will be executed over a defined
Figure 1: Expected Performance ResponseFigure 2: Actual Performance Response Approaching a Bottleneck