This article was orignally published in December, 2001 and refers to Rational Suite TestStudio

"The one thing that matters the most is not how your site behaves under theoretical or simulated conditions, but how well it works when you plug it into the wall and let everyone come hit your box from all across the world"
-- Serdar Yegulalp in "Website Stress-Testing"

This is the fourth article in the "User Experience, Not Metrics" series, which focuses on correlating customer satisfaction with performance as experienced by actual users. After the overview in Part 1, the next two articles explored modeling individual users: Part 2 focused on modeling user delays and Part 3 on user patterns. This article will expand on the topics we've covered so far to discuss modeling groups or communities of users. Once again, this article will both explain the theory behind this kind of modeling and demonstrate how Noblestar has used IBM® Rational Suite® TestStudio® to apply the theory in many performance engineering projects.

Unfortunately, modeling a user community for testing isn't quite as easy as taking the scripts for all of the individuals that we modeled using the techniques discussed in the previous two articles and throwing them together into a suite. There are some special considerations you need to address in addition to those we've already discussed for modeling individual users. I'll explain them here in the context of our online bookstore example. I'll outline how to create a user community model and express that model as scripts within a suite. I'll also discuss when to create multiple models to account for variances in user activity, how to simulate ramping-up and ramping-down periods, and data considerations that must be addressed for user communities.

This article is intended for all levels of TestStudio users but will be most useful to Intermediate tool users and above. Modeling user communities doesn't require complex modification of scripts but does deal extensively with suites in TestManager and assumes familiarity with the creation and use of datapools. Once again, I must stress that the performance results obtained by applying the concepts presented in this series are only as accurate as your overall user community model. Performance measurements will reflect what a user experiences when accessing the system under the same conditions applied during test but may not reflect what a user will experience under different conditions. The next three articles in this series will discuss the actual collection of performance measurements.

Creating a user community model

In the online bookstore example in Part 3, we modeled three different paths that an individual user could take to purchase a New York Times best-seller. In developing the model, we estimated the likelihood of a specific user's choosing each path. I've included our final diagram here (Figure 1) as a starting point for this article's discussion.

Figure 1: Online bookstore "choose a fiction book" paths

(click here to enlarge)

Clearly, there are other functions a user can perform on the online bookstore site, and we want to expand the model to include these so that our testing reflects the full spectrum of possible activities performed by our user community. For instance, the user we modeled was a return user; first-time users would have to enter their personal and billing information and optionally create a username and password before making a purchase. Users of the online bookstore might also want to search for and purchase CDs or check an order's status. In addition, the site might include an option for businesses to open and manage corporate accounts. Figure 2 shows all of these possible activities as part of the site model.

Figure 2: Online bookstore entire site model

(click here to enlarge)

As you can see, this model is much more complex than the previous one. If you study it carefully, you might have some questions about how I arrived at certain parts of it and how well it's actually going to simulate the experience of real user groups for testing purposes. You might wonder:

• How were the percentages arrived at?
• Why are only fiction books and rock CDs searched for and purchased?
• Why is the "Create Profile" path segment placed at the front of the model, when in reality first-time users on a Web site don't often create profiles immediately?

These questions point to some of the major considerations you'll need to address in creating a user community model. I'll discuss them one at a time, plus the related question of how hourly usage rates relate to concurrent users.

Estimating user distribution percentages

The percentages given for each activity in Figure 2 represent the percentage of total users conducting these activities over some period of time, probably a month. Just as for the online bookstore example in Part 3, I arrived at these percentages based on my own experience as a tester and Web user. See "Determining User Patterns" in Part 3 for a reminder of other, more precise ways you can determine user distribution percentages.

You'll notice that the percentages on the book-ordering branch are different in Figures 1 and 2. That's because each percentage in the graph is always normalized over the entire user community. For example, Figure 1 shows that the Name Search activity is conducted by 30% of users who search for fiction books. Figure 2 shows that same activity involving 12% instead of 30% of site users, because only 40% of all users search for a book and 30% of that 40% is 12%. Thus, the two models actually show the same distribution of users on the book-ordering branch. The percentages on the dotted lines have remained the same, since they still represent the percentages of those users who've reached the branch they take off from.

Deciding which options to model

Only fiction books and rock CDs are searched for and purchased in this model, which is probably not realistic. I pretended that the other genres of books and CDs aren't very popular on this particular site and didn't include them only because I was attempting to create a diagram illustrating all of the concepts I wanted to discuss without making it too small to read. In reality, it would be very important to model searching for books and CDs of different genres if the information about them were stored in different tables or databases, because this would mean that searching for them would exercise parts of the system or database that wouldn't be exercised otherwise. As a rule of thumb, a good model for accurate performance-related results should include all system-intensive activities and approximately 80% of all other activities.

It's critical to remember to model system-intensive activities even if they aren't the most popular activities on the Web site. For instance, in our example, because managing business accounts represents only 5% of all user activity, you could argue that it could be left out of the model. But in fact, this activity was modeled because part of managing business accounts is generating monthly usage reports that require the system to extract and compile large amounts of data from the database and then format it for display. Whereas one extra user surfing to a static Web page won't cause a noticeable change in performance, one user running a monthly usage report may cause significant performance degradation. Therefore, this system-intensive activity must be modeled and eventually scripted and evaluated.

Modeling the distribution of activities over time

In our example model, the only time new users create an account is before performing other types of activities from the home page. We all know that first-time users on a Web site don't often create profiles immediately; they usually navigate the site and eventually create an account and enter personal information only when required to do so to continue, and even then, they sometimes choose to leave the site instead. So why do we model profile creation just at the start? Won't this affect the accuracy of the performance results? The answer is that for the results of a performance test to be statistically valid, the correct activities must be executed in the correct distribution over a given period of time rather than in the order in which an individual user accomplishes the tasks.

To help you understand why the exact order of individual activities doesn't need to be modeled, let's look at Web site activity from the server's viewpoint as contrasted with the user's viewpoint. Figures 3 and 4 below depict activity on a typical Web site over the span of an hour (the elapsed time between the "Start of Model" and "End of Model" dashed lines). Each horizontal line across the graph represents a user (or possibly a session or a thread). Each line segment represents a user activity, and different activities are represented by different colors. For the sake of this discussion, we'll say the red line segment represents the activity of loading the home page. For simplicity's sake, we'll assume that the same activity takes the same amount of time for each user. Figure 3 shows what this looks like from the perspective of the server (in this case a Web server).

Figure 3: Server perspective of user activities

(click here to enlarge)

Reading the graph from top to bottom, left to right, we see that user 1 performs the red activity, then blue, black, red, blue, and black. User 2 also starts with the red activity, but then goes to green, purple, and so on. We also notice that virtually any vertical slice of the graph between our start and end times will reveal 10 users accessing the system, showing that this distribution is representative of 10 concurrent users. There are a total of 17 red, 8 purple, 11 black, 11 blue, and 8 green activities at least partially within the time period we want to model. What should be clear is that the server knows that 10 activities are occurring at any given moment in time and that those activities have the distribution just described.

Now let's look, in Figure 4, at the actual distribution of activities by individual users that would generate the server perspective above.

Figure 4: Actual distribution of user activities over time

(click here to enlarge)

This figure shows that 23 individual users actually conducted some activity during the hour time span. You can see that each of those 23 users began interacting with the site at a different time. There's no particular pattern to the order of activities, with the exception that all users start with the red activity, loading the home page. But the distribution of activities over time is identical to that shown in Figure 3: a total of 17 red, 8 purple, 11 black, 11 blue, and 8 green activities occur at least partially within our hour-long period. Thus, each activity is distributed identically over time from the two different perspectives. When hundreds or thousands of users are involved, the variations between the actual distributions and the modeled distributions quickly become statistically insignificant.

Thus, the truth is that from a performance perspective, a server rarely cares which users perform which activities, nor does it care in which order the activities are performed by users, as long as the prerequisite activities are accomplished. (Of course, the server can distinguish between users if the application tracks user sessions, whether through session IDs, cookies, or some other method, but that's the topic of a later article. For now, I'll simply caution you to take extra care when modeling sites that have user persistence to ensure that the modeling method described here is detailed enough to provide accurate results.)

Understanding hourly versus concurrent usage

In the preceding discussion, you learned that 10 concurrent users can look the same to the server as 23 users per hour. As defined in Part 1 of this series, the number of concurrent users is the total number of users who are actually accessing the site or who have active sessions at a specific instant in time. The number of users per hour is the total number of users accessing the site in an hour. Performance tests need to focus on modeling users over time, generally users per hour. The only reason we discuss concurrent user rates is that load-generation tools are licensed by maximum number of users that can be accessing the system concurrently, often referred to as virtual users or virtual testers. I'll explain a little more about hourly versus concurrent usage here so you're clear about what you're modeling.

The term concurrent user was coined in the context of client/server systems where users log into the system in the morning and perform activities throughout the day, so that all users are logged in and interacting with the system at the same time, or concurrently. In this case, if 100 people use the system as part of their job between 8 a.m. and 5 p.m., during that entire time (with the possible exception of lunchtime) there are 100 concurrent users of the system. Partially because of this, it's become common for the capabilities of systems to be measured in terms of concurrent users.

Applying the concept of concurrent users to Web-based applications is a bit problematic, though, because Web users generally don't log into a site and spend the entire day interacting with it. According to research by NetRatings, the international average Web-surfing session is only a little more than 30 minutes long, and 11 different sites are typically visited during this 30-minute surfing session. That means that an average session on a Web site is only about 3 minutes long. If 100 people each spend 3 minutes on a given site between 8 a.m. and 5 p.m. each day, that's a total of 300 minutes spent accessing the site. Because there are 540 minutes between 8 a.m. and 5 p.m., it's entirely possible that those 100 users never overlap -- that is, there may never be more than one user on the system at the same time. Thus, the concept of concurrent usage isn't nearly as useful as that of users per hour when you're modeling a community of Web site users.

Most often I've found that when my clients ask me to test "up to 1,000 concurrent users," what they really mean is "I hope to someday have 1,000 people surf to my site a day, so can you assure me that the performance will be OK?" To make sure they understand the total volume of hourly load they're asking me to test, I do some calculations for them based on their answers to two questions:

1. How much time would you estimate an average user spends on your site?
2. When do you get most of your traffic?

If the answers were "15 minutes" and "between 7 a.m. Eastern time and midnight Pacific time," I would show my client the following math:

• 1,000 concurrent users x 15 minutes per user = 4,000 users per hour
• 7 a.m. ET to 12 p.m. PT = 20 hours per day
• 20 hours per day x 4,000 users per hour = 80,000 users per day
• 80,000 users per day x 30 days per month = 2,400,000 monthly users

This would probably make the client's jaw drop and lead to substituting more realistic numbers in that equation to come up with a more reasonable hourly load for the test.

Since most record/edit/playback load-generation tools are licensed by number of concurrent users, we do need to address how to determine what size license is needed for a performance test. Instead of relying on an estimate of concurrent users (which is hard to arrive at if the site or application you're testing isn't live and doesn't have extensive logs and traffic tracking software), it's safest in my experience to obtain the same number of concurrent user licenses as hourly users intended for the test. This ensures that you're not limited in script creation methods and that you have sufficient concurrent users to conduct specialty tests -- such as stress (high user load distributed evenly over an extended time period), spike (high loads separated by short periods of no load), and hammer (excessively high loads). Such tests are often very useful in detecting bottlenecks and other performance issues but require the use of more concurrent users than actual or expected usage tests. Since cost is often an issue for these tests, the next best approach to concurrent user licenses is to obtain no fewer than 1.5 times the estimated number of concurrent users.

Back to top

Expressing the model as scripts within a suite

Now that you know how to address various considerations in creating a user community model, let's talk about how to turn that model into test scripts. Before returning to our online bookstore example, let's look at how we would create a suite of scripts to represent the distribution of activities coded by color we were discussing earlier.

Recall that over the course of an hour, a total of 17 red, 8 purple, 11 black, 11 blue, and 8 green activities occur at least partially in our example distribution. To create a suite to represent this distribution, we would record three scripts -- the first one for the red activity because that's the starting point for all navigation, the second one navigating blue and black (because they occur with the same frequency), and the third one navigating green and purple (ditto). Then we would create a suite like the one shown in Figure 5, distributing the script execution evenly over the hour to be modeled.

Figure 5: Suite to model user groups for our color-coded example

Now we return to our online bookstore example. Imagine that the activity of creating a profile is the purple activity shown in Figures 3 and 4. The purple activity occurs at different times during a user session in Figure 4 and always at the same time in a session in Figure 3, but it's all the same to the server because in both sessions the purple activity occurs the same percentage of times. Because the server doesn't care what order activities are accomplished in (provided user persistence isn't an issue), we model logging in as a return user and creating a new user profile as separate scripts, and we have the Return User script start the scenario 60% of the time and the Create Profile script start the scenario 40% of the time. Since both of these activities end at the home page, and each of the other scripts starts at the home page, these can easily be organized into a suite to represent the correct model.

While recording a complete script for each possible navigation route through a system often makes sense when testing a client/server application, it isn't really a viable solution for Web applications with a diversity of possible paths. If we tried to do it for our online bookstore site model, we would end up with 102 individual scripts. In Part 3, we discussed how to limit the number of scripts by using three different recording and editing methods. Using those scripting methods in combination with the modeling concepts discussed above, we would end up with 13 scripts. Figure 6 shows in green the scripts required. The activities left in blue become part of the scripts named in green. For example, the Select Book and Help activities are included in the Name Search script.

Figure 6: Scripts (shown in green) needed to model the entire online bookstore site

(click here to enlarge)

The suite shown in Figure 7 is one way to create this model; there are other ways the model could have been scripted and organized into a suite, but this is the way I chose. I didn't expand all of the groups and scenarios, but I used the same methods for each. You'll note that I used synchronization points (labeled "Ramp-Up") to simulate ramping-up periods, as discussed later under "Simulating Ramping-Up and Ramping-Down Periods."

Figure 7: Suite to model user groups for our online bookstore

(click here to enlarge)

Back to top

Accounting for variances in user activity

Sometimes one user community model isn't enough to ensure accurate performance testing. Research and experience tell us that user activity on a Web site can vary greatly over time. To ensure test validity, we need to evaluate levels of activity by time of day, day of week, day of month, and time of year, and then develop as many models as required to account for most variances in expected user activity.

For example, consider an online bill payment site. If all bills go out on the 20th of the month, activity on the site immediately before the 20th will consist largely of system administrators updating accounts and importing billing information; immediately after the 20th, customers will be viewing and paying their bills until the payment due date of the 5th of the next month, as depicted in Figure 8.

Figure 8: Online bill payment site, activity by date

In this example, the performance of the system could be very different between the 15th and the 20th when account information is being imported as compared with the period between the 20th and the 25th when customers are viewing and paying their bills. For this reason, two very different user community models must be created and tested. The first model will include all three activities, while the second will include only "view statement detail" and "pay bill." The second model can then be executed with various distributions of users performing those two activities to determine if there's a performance variance based on the distribution of those activities.

In your own situation, you may need to develop special models to represent sustained normal and spike usage conditions. A sustained normal usage condition is when the application is being used at normal or expected loads but over an extended period of time, and a spike usage condition is when abnormal or unexpected surges in usage loads occur. Scenarios that drive these conditions vary greatly from one system to another. For some systems, it's valid to simply define the number of users to be modeled and the length of time for the load to be applied, using the same model that's been developed for typical usage. For other systems, completely separate models may be required if the usage conditions also involve a significant deviation from the typical usage model (as in the example above).

Back to top

Simulating ramping-up and ramping-down periods

Another consideration when you're modeling groups of users is how to simulate ramping-up and ramping-down periods. Let me explain what these are by way of our online bookstore example, and then show you a method I've devised to model these periods. I'll also discuss the shortcomings of two common ways of handling ramping.

Assume that our online bookstore is visited almost exclusively by customers in North America and that the server resides in the Eastern time zone. By analyzing the log files generated during a period of one month, we determine that about 11,000 customers visit the site each day, the average peak hourly usage during the time observed is approximately 1,200 users per hour, and the peak concurrent user load is 500. By plotting the log file information, we generate a chart showing the average hourly usage (the number of users conducting activities on the site each hour) during a typical day (see Figure 9).

Figure 9: Online bookstore, average hourly usage over a typical day

(click here to enlarge)

As you can see, the site is essentially not used between 3 a.m. and 6 a.m. EST. Usage peaks at about 5 p.m. EST. It ramps up fairly evenly from 8 a.m. until noon and ramps down fairly evenly from 5 p.m. until midnight. In other words, it takes about four hours to ramp up to and seven hours to ramp down from the user loads we're interested in testing: a peak usage of 1,200 hourly users and a sustained usage of 1,000 hourly users over eight hours. So how do we get up to those usage rates in our test, and how do we ensure that users are distributed properly once we get there?

One common practice would have us model a four-hour ramp-up and a seven-hour ramp-down period. But in this case, the ramping-up and ramping-down periods only need to be about 10 minutes long for an accurate test. I'll explain why by showing you a hypothetical example. The graph in Figure 10 is similar to the activity graphs we discussed earlier in the article, but this time each line segment represents an entire user session rather than an individual activity. The green segments represent users whose sessions occur at least partially between the model start and stop times. The red segments represent users whose sessions occur entirely outside the time period we want to model.

Figure 10: Actual distribution of users over time

(click here to enlarge)

Because we're interested in the performance of the system only during the time between the start and end points, no performance data from outside of that time will be collected. But a user obviously can't start in the middle of a session on the site, so all of the green users need to be included. The ramp-up time becomes the time between the beginning of the first included user session and the start of the model, and the ramp-down time becomes the time between the end of the model and when the last included user completes a session, as depicted in Figure 11.

Figure 11: Modeled distribution of users over time

Modeling this way doesn't take into account such things as memory leaks or other performance issues that occur as a result of cumulative use, whereas extended ramping periods sometimes do bring such issues to light. The tests mentioned above (stress, spike, hammer) check for those types of performance issues and should therefore be included in your overall performance testing plan, even though they're not valid for determining user experience.

One way to create a suite to generate a load with this type of ramping-up and ramping-down periods is to use synchronization points, as illustrated in the suite shown in Figure 7. Figure 12 shows the run properties of those synchronization points. The time that's entered in the "Maximum time" field is the ramp-up time as arrived at by the method I've just outlined. That amount of time can also be interpreted as "a few seconds shorter than the time it takes your longest script to run to completion," which we can determine by running our script individually and noting the run time. In the case of our online bookstore example, our imaginary research showed that 600 seconds was the correct time.

Figure 12: Run properties of the synchronization points shown in Figure 7

What we see in the suite is that when the performance test is executed, all of the virtual testers are released into user groups according to the assigned percentage distribution. Then each virtual tester is released into the synchronization point. While synchronization points are normally used to align virtual testers with one another, in this case we're using them to do just the opposite -- to stagger the times when the virtual testers begin. User start points are distributed uniformly over 600 seconds (10 minutes), and each scenario is then repeated three times. With just three iterations of each scenario being executed, this test will run for only about 30 minutes. If we wanted to simulate an hour of actual usage, we'd need to schedule more iterations.

Accomplishing ramp-down is simple: because the actual times when users start are staggered, users will also complete their tasks at different, staggered, times. Ultimately, we'll only evaluate times collected between the model start and end times, but that's discussed in Part 7.

I promised to tell you about the shortcomings of two common ways of handling ramping. I've already mentioned that I regard as unnecessary the common practice that would have led to us model a four-hour ramp-up and a seven-hour ramp-down period. The other common approach to ramping is a step-up approach, as exemplified in Figure 13.

Figure 13: Example of the step-up approach to ramping

(click here to enlarge)

This model represents several groups of users, where each member of a given group starts interacting with the system at the same moment in time. Reading the chart from left to right, we see that at exactly the same instant (the instant the test run starts), 20 users request the home page; at exactly 2 minutes and 30 seconds into the test run, 10 more users request the home page; 30 more come in at exactly 6 minutes; and so on. This is clearly not representative of how real user groups would interact with the system and therefore would result in the actual outcome being incorrect or at least misleading.

One of the reasons this type of modeling is done is to enable comparison of timing results at different user levels during a single test run. But in fact, this approach makes it impossible to determine if increased times are due to the current total user load or are a result of the cumulative effects of users, many of whom have already exited the system at any given moment. In the methods we've discussed, separate tests are created to detect performance issues related to load and those related to cumulative effects. These types of tests will be discussed in detail in Part 8.

Back to top

Data considerations for user communities

It's important to think about data early in the modeling process. For purposes of this article, I've assumed that you know how to create datapools for input data requiring variation. The following discussions address how to think about which data should be varied and how to maintain the database for test accuracy.

Deciding which data should be varied

On the surface, it would seem that all data that a user enters should be varied and unique for each user. But you need to consider that every piece of data that's varied using datapools adds overhead to a test, ultimately limiting the total number of virtual testers that can be executed on a given set of hardware. Varying every piece of data also greatly increases the time it takes to create tests. If you have infinite hardware and time resources, this is the most accurate approach, but since most of us don't, it's important to limit the varied data to the minimum necessary to create accurate tests.

Here are the types of data that need to be varied:

• Any data that must be unique to identify a user, such as username and password, or credit card number.
• Data that can vary greatly in size. For instance, if we're testing a site that has a text field that can receive input of anywhere from 0 to 5,000 characters, this field must be varied to ensure that performance based on different field sizes is accounted for. You don't need to simulate all possible data sizes; four sizes of data distributed across all users is normally sufficient. For example, research may show that 25% of users leave the field empty (empty), 25% enter approximately 250 characters (small), 25% about 1,000 (medium), 20% about 3,000 (large), and 5% use the full 5,000 (jumbo) available. This distribution can easily be simulated with 20 fields in a datapool. This datapool would have five each of empty, small, and medium entries, four large entries, and one jumbo entry.
• Data that causes the application to respond differently. In our online bookstore example, CD genres searched for would need to be varied if each genre were stored in a separate database table. Failing to vary this data during a performance test would cause all users to access a single table, thus causing unrealistic stress on the database.

The remainder of the data required to execute performance tests doesn't normally require variation. For instance, user zip codes can probably all be the same, unless the field will be used later to execute a test requiring server-side processing (like searching by zip code).

Maintaining the database

As with all other components of the system under test, the database should be an accurate representation of the production environment, both in types and volume of data. If the system is live, you can take a snapshot of the existing database and use this in the test environment. If the site isn't live, you must make a reasonable estimation of the total data volume and data variance. This process may be more or less difficult for any given application.

Once the database is initially populated, it must be maintained. Naturally, if the system you're testing doesn't actually change any data in the database but only reads data, then no further maintenance is required. If, however, the system under test includes activities that read and/or write data to the database, the database must be reset after each test execution to ensure that subsequent test results are actually comparable to one another.

When time allows, identical tests should be executed with differing volumes of data in the database to determine when the volume of stored data becomes the system bottleneck. Generally, the database administrator should handle database maintenance and should be involved early in the modeling process so she or he can generate data and/or scripts to reset the data while scripts are being recorded. Otherwise, testing will be stalled while the data issues are managed.

Back to top

Modeling back-end functions

I don't want to spend much time discussing the need to account for back-end functions within a user group model, but I do want to remind you to consider these functions. If you're testing global or complex systems that periodically run batch processes, replication, or backups while users are accessing the system, it's imperative to execute tests while these back-end activities are occurring. This is the only way to determine the associated performance degradation from a user's perspective. A short conversation with the system administrator will normally reveal any back-end functions that may affect performance.

Back to top

Now you try it

If you've been doing all of the sample exercises, you'll find that these exercises are a little different. Ideally, I would attach log files, WebTrends reports, market research, and other materials and ask you to analyze them, create a model, and then compare it with the model I created. But since this isn't realistic, I've provided a model and some usage data for you to work with in doing the following two exercises. I do encourage you to evaluate some applications and develop your own models for practice.

Create a suite to match a model

Referring to the model in Figure 14, create a Rational TestStudio suite that when executed will represent the model and will generate the target load for one hour. Assume that all scripts take approximately 15 minutes (900 seconds) to execute, implying that average users spend about 15 minutes surfing the site each time they visit. Further assume that each solid horizontal line on the graph represents a single script.

Figure 14: Model of a financial planning Web site

(click here to enlarge)

To create empty scripts with the names on the horizontal lines, simply launch Rational Robot, choose New > Script from the File menu, and enter the appropriate name. Compare what you've done with my solution, shown in Figure 15.

Figure 15: Example solution

(click here to enlarge)

This suite is straightforward, although I should mention that the First-Time User script is only executed in conjunction with the Life Insurance Planner script. This is because both activities are executed by 25% of all users. Since the First-Time User script and the Return User script both end at the home page and this particular system makes no distinction as to how a user initially gets to the home page, this is a valid approach.

Each scenario has been scheduled to execute five times. Since each script runs for approximately 15 minutes and the first iteration will be discounted as ramp-up, that results in a one-hour test.

See the properties of the synchronization point in Figure 16.

Figure 16:Properties of the synchronization point

Determine number of concurrent users

Given the information in the preceding exercise and in Figure 17, determine the number of concurrent users required to simulate the peak user rate. (Hint: Always model performance tests to validate peak hourly usage.) Then look at my solution, following Figure 17.

Figure 17: Financial planning Web site hourly usage

(click here to enlarge)

From the chart, we see that the peak hourly usage is 3,000. We know from the preceding exercise that the average script (which if modeled properly represents the average user) accesses the site for 15 minutes, or 1/4 hour. Multiplying 3,000 users/hour times 1/4 hour gives us 750 concurrent users. (The reverse is also true: 750 concurrent users every 15 minutes equals 3,000 hourly users).

Back to top

Summing it up

This article completes our discussion of modeling groups and users. Over the last three articles, you've learned how to model tests to simulate real users and user communities and how important that is to obtaining valuable test results. You've also read about some of the commonly held beliefs about user modeling and why they don't lead to tests that represent actual users. With Part 5 we begin a three-part exploration of what measurements to collect and how to collect them using IBM® Rational Suite® TestStudio®.

Back to top

References

• "Website Stress-Testing" by Serdar Yegulalp (ExtremeTech Web site)

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Creating a user community model
• Expressing the model as scripts within a suite
• Accounting for variances in user activity
• Simulating ramping-up and ramping-down periods
• Data considerations for user communities
• Modeling back-end functions
• Now you try it
• Summing it up
• References
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers