Hi, It is possible to load a jtl after the test, you will also be able to check the throughput.
The reason the throughput might not be the expected one can vary. It might be that the way you designed a single "virtual user session" is not ok for this goal (requests in the thread) and then you cannot achieve this much throughput with only 800 threads (so check that the script does what you think it does first of all) and then, if the script is ok, if the server response times increase to a value that is unexpected, than the capacity to generate throughput will decrease. Each thread is a single line of execution, it waits for the previous response to arrive in order to continue its execution... Quick example: * simple script: 100 threads - 1 thread: is designed to make aprox. 10 requests per second (this assumes response times are ~100ms in average) - therefore, the test (100 threads) can achieve 100x10=1,000 requests per second - I add a throughput timer because I do not want to make more than 1,000 rps at any time (its a hard limit in my app, or whatever other reason) What happens if my test bed doesn't work as expected? Lets say that network setup brings a 100ms latency in addition to the apps expected 100ms, and then recorded response times are 200 ms instead of 100ms. Than my throughput will be 500 rps. What I do in these cases, I design a test with 1,000 rps set in throughput constant timer which I know is what I would expect out of 100 users. But, the script will be configured to spawn 300 threads instead of 100. This way, the script will have more threads that are on hold, and they can sustain the rate of 1,000, even if some of the threads are waiting for responses. This is what would happen in real life, if server responds slower and slower, user requests keep arriving, so its another scenario to test for. Cheers, Adrian S On Sat, Aug 10, 2013 at 8:14 PM, hame <hame...@gmail.com> wrote: > I did notice the throughput in the report. But looks like those number are > way-off and I want to validate this. > > Currently I am running 800 concurrent thread to simulate users. I have also > used the constant throughput timer to make sure I get 600 request per > second. But when I check the throughput I get close to 350. > > > Is it possible to calculate the number of request call from Jtl file? If I > group the records based on the second. > > > On Sat, Aug 10, 2013 at 3:12 AM, Deepak Goel <deic...@gmail.com> wrote: > > > Yep > > > > On 8/10/13, Shmuel Krakower <shmul...@gmail.com> wrote: > > > The report contains the throughput. Isn't that what you are looking > for? > > > On Aug 10, 2013 9:41 AM, "Deepak Goel" <deic...@gmail.com> wrote: > > > > > >> Hey > > >> > > >> Little's Law: > > >> > > >> Average number of request per second = Number of Concurrent Users > > >> divided by (Response Time and Think Time) > > >> > > >> Average number of request per second = Number of Concurrent Users / > > >> (Response Time + Think Time) > > >> > > >> Think Time is the time between two subsequent request. > > >> > > >> :) > > >> Deepak > > >> > > >> > > >> On 8/10/13, hame...@gmail.com <hame...@gmail.com> wrote: > > >> > Currently I am using JMeter to generate load for webapp. I am able > to > > >> > simulate 800 simultaneous users. I store the test result in output > > file > > >> to > > >> > get the aggregate report. I am able to get the avg response time for > > >> > the > > >> > request but report doesn't contain average number of > request/response > > >> > per > > >> > second. Is there any way to calculate the number of > request/response > > >> > per > > >> > second? > > >> > > > >> > > > >> > > > >> > Thank you, > > >> > > > >> > > > >> > > > >> > > > >> > ----- > > >> > Technical blog : code4reference > > >> > LinkedIn : Rakesh Kumar > > >> > -- > > >> > View this message in context: > > >> > > > >> > > > http://jmeter.512774.n5.nabble.com/Number-of-request-per-second-tp5717812.html > > >> > Sent from the JMeter - User mailing list archive at Nabble.com. > > >> > > > >> > > --------------------------------------------------------------------- > > >> > To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org > > >> > For additional commands, e-mail: user-h...@jmeter.apache.org > > >> > > > >> > > > >> > > >> > > >> -- > > >> Namaskara~Nalama~Guten Tag~Bonjour > > >> > > >> > > >> -- > > >> Keigu > > >> > > >> Deepak > > >> 7350012833 > > >> deic...@gmail.com > > >> http://www.simtree.net > > >> > > >> Skype: thumsupdeicool > > >> Google talk: deicool > > >> Blog: http://loveandfearless.wordpress.com > > >> Facebook: http://www.facebook.com/deicool > > >> > > >> "Contribute to the world, environment and more : > > >> http://www.gridrepublic.org > > >> " > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org > > >> For additional commands, e-mail: user-h...@jmeter.apache.org > > >> > > >> > > > > > > > > > -- > > Namaskara~Nalama~Guten Tag~Bonjour > > > > > > -- > > Keigu > > > > Deepak > > 7350012833 > > deic...@gmail.com > > http://www.simtree.net > > > > Skype: thumsupdeicool > > Google talk: deicool > > Blog: http://loveandfearless.wordpress.com > > Facebook: http://www.facebook.com/deicool > > > > "Contribute to the world, environment and more : > > http://www.gridrepublic.org > > " > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org > > For additional commands, e-mail: user-h...@jmeter.apache.org > > > > >
