posted 07-04-2002 02:18 AM         

where can i acquire those so-called rules of thumbs such as:
1. "according to Internet best practices, 40% of the daily traffic occurs within 4 hours"
2. 8 seconds load-up time
3. is there any relation btw 'active user' and 'concurrent user'? can i declare x Concurrent User == y active user???
4. How slow is 'too slow'.
5......
i'm looking for 'industry-wide rules of thumbs' as such. any lead??

Thanks in advance.

posted 07-04-2002 09:36 AM         

quote:

---

Originally posted by chear:
am preparing a load/performance test report, just wonder what should the content be?

where can i acquire those so-called rules of thumbs such as:
1. "according to Internet best practices, 40% of the daily traffic occurs within 4 hours"
2. 8 seconds load-up time
3. is there any relation btw 'active user' and 'concurrent user'? can i declare x Concurrent User == y active user???
4. How slow is 'too slow'.
5......
i'm looking for 'industry-wide rules of thumbs' as such. any lead??

---

1. Depends on your application/Site. Only monitoring will give you a full answer to this. You can also investigate the type of users you might attract, they geographical location, special (business) event for these users that would trigger them to visit your site etc. Form there you can probably make some predictions.
2. Do a search on this forum, this topic has been covered before and you might find what you need.
4. Too slow is when your response requirements are not met.

posted 07-18-2002 11:27 AM         

3. Active and Concurrent users were both origionally Client Server terms that have been brought forward to the Web world that don't very well apply. I could make a case for saying that Active users are Web users with a session that hasn't timed out and Concurrent users are logged in users of a client server application. I could also make a case for there being a distinct difference between the two in the Client Server world, but your question leads me to think you are focused on web.

posted 07-19-2002 11:39 PM         

You can estimate the two parameters for your site. For example, the requirement for you site is to support 100 logins/min, and the average user will spend 5 mins on the site and browse 10 pages, and also let's assume the session timeout for the system is 10 mins. Then the total sessions your system needs to support = 100/min *(5 mins + 10 mins) = 1500, and the hits/min = 100 (logins) /min * 10 (pages) = 1000 hits /min.

posted 07-22-2002 07:38 AM         

Also note that Chainey is talking about page hits, not web server hits. Every one of your pages is like to hit the server a different number of times. I have seen individual pages hit the server anywhere from once to over 150 times to paint the page.

As you can see, the math can get very complicated very fast if you go that route. I recommend establishing a workload distribution with all of the wait states and parameters before testing, the collecting and reporting on User Experience (end to end response time) for different loads using that distribution. Then you are comparing "apples to apples" and ultimate find the max load that provides "acceptable" performance. My opinion is that other tests are useful to track down bottlenecks, and determine statistics for individual components, but are not often what the report readers are interested in. Those statistics usually go in an email to the owner of the tested component.

I'd say report on response time by page over varying user loads (possible over varying connection rates), don't make value judgements.

posted 07-29-2002 08:02 PM         

quote:

---

Originally posted by RSBarber:
You can find some "reliable" source to quote whatever you want to find. The key to reporting performance results documents is to establish the client's Performance Acceptance criteria before starting to test. Then report as compared to the individual clients criteria. If you are interested, I have sample verbage on how to phrase the criteria.

3. Active and Concurrent users were both origionally Client Server terms that have been brought forward to the Web world that don't very well apply. I could make a case for saying that Active users are Web users with a session that hasn't timed out and Concurrent users are logged in users of a client server application. I could also make a case for there being a distinct difference between the two in the Client Server world, but your question leads me to think you are focused on web.

---

Hi RSBarger, would u please send me your sample verbage, cheers.

3. My understanding of active and concurrent user definition merely applicable for web application. Was told that active users are those who perform the web-transaction WITH think-time, (i.e. there're waiting btw pages, user input ..) and concurrent user simply performs the transaction as robot (WITHOUT any pause in between). in a typical web load test, it is normally advisable to conduct the test with concurrent VU. understand there's a way to correlate the 'Active VU':'Concurrent VU', any1 would kindly explain the method used in deriving the ratio?? thanks in advance

------------------

posted 07-30-2002 02:01 AM         

quote:

---

Was told that active users are those who perform the web-transaction WITH think-time, (i.e. there're waiting btw pages, user input ..) and concurrent user simply performs the transaction as robot (WITHOUT any pause in between). in a typical web load test, it is normally advisable to conduct the test with concurrent VU. understand there's a way to correlate the 'Active VU':'Concurrent VU', any1 would kindly explain the method used in deriving the ratio?? thanks in advance

---

This is one of THE main problem areas for misunderstanding in Performance testing. Unfortunately there is no universally agreed definition. I now tend to use "concurrent with think time" and "concurrent without think time", just to be sure.

As far as converting from one to the other, it's also very difficult, as different web pages will require different "real" think times. You'll spend longer on a page with a 20 field form than on a static page with 2 links. So the ratio will depend on your application.

posted 07-30-2002 07:11 PM         

Agree with that. but is there any method that can be used to determine the ratio between the two. for example, conduct a test with some constanst factors, but varying the user think-time. based on the result, thus one could derive the ratio. any detail implementation of such?? thanks in advance.

------------------

posted 08-04-2002 09:22 AM         

Here is an example straight from a Performance Engineering Strategy document I recently wrote on a client engagement...

"This performance engineering effort will attempt to achieve the following performance goals:

- Static pages will be fully rendered in 3 seconds or less, 95% of the time, when accessed via 10 Mbs LAN, under a 1000 user-load, as described by the workload distribution in Section 2 of this document.

- Static pages will be fully rendered in 6 seconds or less, 95% of the time, when accessed via 56.6 kbs modem, under a 1000 user-load, as described by the workload distribution in Section 2 of this document.

- Search Results pages will be fully rendered in 5 seconds or less, 95% of the time, when accessed via 10 Mbs LAN, under a 1000 user-load, as described by the workload distribution in Section 2 of this document."

You can see how this section of the document can get long very quickly, but I think it is important.

Remember to list these things as goals, not numbers that the client can hold you contractually liable for unless that is your intent.

posted 08-04-2002 05:51 PM         

quote:

---

Originally posted by RSBarber:
- Static pages will be fully rendered in 3 seconds or less, 95% of the time, when accessed via 10 Mbs LAN, under a 1000 user-load, as described by the workload distribution in Section 2 of this document.
[/B]

---

no worries in replying late. Anyway, hope you enjoy your honeymoon.

Am puzzled on how to simulate a 1000 user-load. understand there're some models that can be used, and what are they? how to justify 1000 user-load with think-time, or without think-time, concurrent, or ramped up??

posted 08-05-2002 11:42 AM         

The shortest possible answer to your questions, is that you have to define that with your client. In the case of the verbage above, a 1000 user load was defined to be 1000 users HOURLY doing all the things that "typical" users do in the amount of time it would take "typical" users to do it.

This particular engagement had 15 navigation paths through the application, each with several optional navigation routes. Each of those paths were distributed as a percentage of the total number of users. So you can see it can get fairly complex fairly quickly.

The point is, that when collecting User Experience Measurements (end-to-end response times) it is imperative for your test to simulate the actual user community (or predicted user community) as accurately as possible.