posted 02-06-2002 02:02 PM         

HPS = hits per second, the data from WebLoad report
Tr = average response time, the data from WebLoad report
Ti = the average interval between 2 hits for a individual user

Tr+Ti = the average interval between 2 attemps of hits for a individual user
hps = 1/(Tr+Ti) = the hits per seconds generated by a individual user
#CU = HPS/hps = HPS/(1/(Tr+Ti)) = HPS*(Tr+Ti) = the # of concurrent users

#CU=HPS*(Tr+Ti)

The key is the Ti! If we can get a number for it, we can finally find the #CU.

did I miss anything ?

posted 02-06-2002 03:00 PM         

peg

posted 02-06-2002 03:28 PM         

I didn't take the usage of system resource into the formula . Cauze the test load has nothing to do with it. The test load is a different thing from system capacity.

I didn't say it is used to calculate the capacity of a specified system. I just want to estimate the performance for the system under various work load.

posted 02-11-2002 11:20 AM         

If my interpretation of this formula is correct, the formula and theory are invalid. For example,

Lets imagine the following test with Webload:

10 Virtual Users,
The test script thinktimes are set to zero,
The test script measures for response times,
The test script contains 7 transactions (or 7 webpages to cycle through)
The script runs for 10 minutes after the ramp up goal is met.

If you ran this imaginary test and found that the average virtual user response time was 1/3 of a second, that would mean each virtual user could execute 3 transactions (or hits) per second. Therefore 3 * 10 = 30 Transactions per second (or Hits). Furthermore, we find it takes an average of 2 1/3 seconds for a complete cycle (or session) to complete: 3 transactions the 1st second, 3 transactions the 2nd second, 1 transaction during the 3rd second. The bottom line though, is the number of concurrent users is 10 because you have 10 virtual users. You can't make your 10 virtual users come out to some higher number of concurrent users no matter what. The individual virtual users are operating transaction by transaction and round by round- thats it. If you want to test higher concurrent users you are going to have to increase the number of virtual users you are testing with.

Because of the way that Web Applications can be stateless, when people consider 'Concurrent Users' they are usually speaking of the number of users that are 'attacking' a 'target' during overlapping sessions. As opposed to 'Simultaneous Users' which are going to far as to perform their actions at the exact same time- (all users posting at the same time). Concurrent Users Tests MUST consider server resources- if you are not doing so then you are not testing for Concurrent Users. Server resources are one of the factors that limit systems from handling higher numbers of concurrent users.

Lastly, if you had to you could roughly estimate the number of supported concurrent users that you can handle based on the number of virtual users tested with VS the CPU/memory/disk/etc utilization that the target experienced during the test.

TestguyTony

posted 02-12-2002 11:55 AM         

quote:

---

The bottom line though, is the number of concurrent users is 10 because you have 10 virtual users. You can't make your 10 virtual users come out to some higher number of concurrent users no matter what.

---

the # of Concurrent Users and the # of Concurrent Requests

Let's start with how to define the two numbers. Actually, I didn't find the definition for the # of concurrent users from the internet. In my opinion, every individual who are periodically contributing his/her click to our web site is a concurrent user, no matter whether he/she is doing so currently. Potentially, all users can be our concurrent users. The word "concurrent" means the clicks of the user are independent from the clicks from other users. Imaging two users are sharing one computer all the time, their clicks are not independent from each other, so they should be regarded as a single concurrent user. On the other hand, the definition of the # of concurrent requests is much easier to be understanded. At any moment, the requests which are submited by the users, and haven't been finished, are concurrent requests.

From the definition above, we can determine that the # of concurrent requests is the one which is for describing the concurrency of the system. In our webload report, the load size ("the number of threads") is the approximate value of the # of concurrent requests. (the # of virtual users is not the # of concurrent users) Why ? Because, we are using 0 thinking-time in our script, so in the most of the life-time of a thread, the thread is waiting for a request to be responsed, and at any moment, the number of the threads represents the number of the requests ongoing.

Let's introduce the thinking time(sleeping time) "Ti". If "Tr" stands for the average response time, "Ti" stands for the average thinking time, "#CR" is the # of concurrent requests and "#CU" is the # of concurrent users. We can easily deduce a formula :

#CR = #CU *( Tr / (Tr + Ti) )
=>
#CU = (#CR / Tr) * (Tr + Ti)

if "HPS" stands for hits per second, then

#CR = HPS * Tr
=>
HPS = (#CR/Tr)
=>
#CU= HPS * ( Tr + Ti )

It's the same as the formula I recommended in my first post.

When "Ti" is zero, #CR=#CU.

quote:

---

Concurrent Users Tests MUST consider server resources- if you are not doing so then you are not testing for Concurrent Users.

---

The # of concurrent users is not a property of the server. Instead, it is a measure to the work load we are burdening the server. If we want to use it to describe the system capacity, we have to offer other parameter with it like average response time "Tr", average thinking time "Ti".
So does the # of concurrent requests.

The process you work these numbers out using the system resources is not testing, it is calculating.

For example, assuming the application server 's threads pool size is 25. Can our system only handle 25 concurrent requests ? We can only say the server can only handle 25 requests at a time. But the whole system (including Queues in web server , app server) can handle more requests. To answer this question you should give me the acceptance of the response time, then we can test it using WebLoad or whatever tools.

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