posted 07-24-2002 09:08 AM         

quote:

---

Originally posted by RSBarber:
If any of you is interested, I would be happy to mail you one of the articles in a series that I am writing that talks about User Community modeling and addresses concurrent users to some degree (mostly it says "don't use this term"). The article is too large to attach - 300k zipped

It is part 4, so there will be some reference to earlier articles, but it still makes sense as a stand alone.

Particlularly after the discussion above, I'd love to hear people's reaction to the article.

---

Scott,

Can't you just upload your articles to the qa downloads area?

posted 07-24-2002 10:23 AM         

quote:

---

Originally posted by rstens:
Scott,

Can't you just upload your articles to the qa downloads area?

---

Roland,

We are currently converting the articles to PDF versions so I can do exactly that. Currently, I only have roughly formatted word docs (the word docs are then converted to HTML to fit on the Rational Template for RDN). I will post them as soon as the conversion is complete.

posted 03-18-2003 11:55 AM         

So the formula to calculate the purchase of required VUsers would be:

# Of Average Sessions / hour
Divided by
The average session duration / hour

i.e.
3500 Sessions
5 minute duration
3500 / (60 / 5)
= 291.67

Do you agree?

However, do you base your purchase of VUsers on average usage of the site, or peak usage periods?

posted 03-18-2003 12:41 PM         

Having said that, if the average session length is really on 5 min - you might be able to do the same math substituting for a smaller time frame - like 20 min. - to get a smaller number of licenses.

When you think in terms of hourly users, remember that if the user is only active for 5 min, you can theoretically get 12 completely unique virtual users from the perspective of the server out of 1 Virtual Users license.... if that makes sense... a more realistic number would be 6, but that really depends on how you structure your scripts/suites.

I always tell folks to get a number of licenses the same as the peak hourly usage - and when they can't afford that, then I start doing actual calculations.

posted 03-19-2003 07:58 AM         

I couldn't agree with you more. Yes, the maximum concurrent users count is significantly lower than the possible number of users during the normal performance test. If the goal of the load test is to simulate 300 concurrent users (means they are concurrently executing the different transactions), what the possible number of users I need to run? (no stress testing)

posted 03-19-2003 08:42 AM         

Remember, we are talking about how many licenses to buy, not how many users to simulate. If I have the same number of licenses as the maximum number of expected hourly (not concurrent) users, I promise you that I can create tests that accurately simulate any non-stress load you can map without significant script modification.

If you have 300 hourly users, and 300 VU licenses, you can get thousands of independant hourly users - with realistic delay's - just by assuming a 300 user concurrancy. This is why I try to work with users/time and session durations rather than the concept of concurrency. Concurrency really has little meaning in the web world anyway - the connections aren't really persistent, even with keep-alives.

Buy licenses to cover max hourly usage (if you can afford it) it will make your life easier, then think in terms of usage rates and patterns. Things will work out much easier for you.

posted 03-19-2003 11:42 AM         

Sorry that I didn't make my point clear enough. I am trying to figure out how many users I need in order to simulate 300 cocurrrent users at any point during a one hour timeframe(all are doing transactions at the same time, but can be different transactions)before buying the license.

Given the use of thinktime in the script, 300 vuser license definitely can't produce the 300 concurrent load. So does anyone have any idea what number is large enough to produce 300 concurrent load? The "transaction per hour scheme" does not work for us, we need to test the 300 weblogic threads.

posted 03-19-2003 01:07 PM         

Is that any clearer? I wish I could sit with you for about 15 min and do the calc - it's not hard when you have all the data - it's just knowing what questions to ask based on the last answer to get the data that's tough.

posted 03-25-2003 12:30 AM         

case 1: When ur apploication goes live
you can very well expect arount 50-80% of total users accessing the application within short time .
For this scenario identify the most probable transactions.

Case 2 : Normal usage, you can expect around 20-30 % of total users , they could be doing or performing almost all of the possible transactions on your application.Here you can very well categorise users into diff groups depending upon the task they perform.

CAse 3 : Peak Usage, here you can expect 40-55% of total users accessing ur application .

so design your test scenarios accordingly.

All the Best.
Anup

posted 03-25-2003 04:23 AM         

And it doesn't address the issue of "concurrency".

I was re-reading an article by Alberto Savoia yesterday which meerly spend a page talking about concurrent usage which concluded with "I hope by now you have eliminated the term 'concurrent users' from your vocabulary. I have written a related article that took 10 pages and didn't end with nearly as strong language, but made the same point. (I guess that makes me verbose)

If you are think in terms of concurrent usage, you probably need to rethink how you are defining load.

posted 03-25-2003 10:35 PM         

You are right Barber,
I used these statistics for intranet based application such as appraisal system.
We had logs of usage of application (older version). Its always helpful to have usage statistics with you while designing user load to test.
The percentage mentioned were for concurrent users as the application which I tested was similar to appraisal system , actual number would vary depending upon the application and intended users.

Anup