Return-Path: X-Original-To: apmail-jmeter-user-archive@www.apache.org Delivered-To: apmail-jmeter-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A688610AF5 for ; Mon, 12 Aug 2013 11:31:14 +0000 (UTC) Received: (qmail 61820 invoked by uid 500); 12 Aug 2013 11:31:12 -0000 Delivered-To: apmail-jmeter-user-archive@jmeter.apache.org Received: (qmail 61785 invoked by uid 500); 12 Aug 2013 11:31:01 -0000 Mailing-List: contact user-help@jmeter.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "JMeter Users List" Delivered-To: mailing list user@jmeter.apache.org Received: (qmail 61758 invoked by uid 99); 12 Aug 2013 11:30:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Aug 2013 11:30:56 +0000 X-ASF-Spam-Status: No, hits=3.8 required=5.0 tests=FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of asp.adieu@gmail.com designates 209.85.220.46 as permitted sender) Received: from [209.85.220.46] (HELO mail-pa0-f46.google.com) (209.85.220.46) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Aug 2013 11:30:51 +0000 Received: by mail-pa0-f46.google.com with SMTP id fa1so7397317pad.19 for ; Mon, 12 Aug 2013 04:30:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=mA0lhVNCaHL0w25stlImyMFIeYu4uTYg9MAluR2yfo4=; b=vge7kQ31M02RGuyabwWYSk9Dn66i+MuqzlYVH2mgEyXmO5RYBdqFVHqpE/PbAyb8e6 C6TvdRLffXX/IFOh/I0FPw6zdpvGAGn4VqB/sU2AsiJLThCl7VBk0r13xZC10F+963D9 4JQBBjPIqUfB4qJKhW/QfRaCFoP1OSTxLe7+6llpew26qp0+EQ/xczsZeKf5r2d7p3uP bOqadgPY+ozzLdDPmxP/dZPZkCOGc7FomSS9VdlWvSSwqjCjM4/B8YcPhi6ukUVzE682 8XKBv4dEyjjSiJYRqFel45m7KXj/7VJpnzJi1nf3+/YdyOd6/OHkkuspZVIl9YKNW391 cVHA== MIME-Version: 1.0 X-Received: by 10.66.164.136 with SMTP id yq8mr542216pab.67.1376307029637; Mon, 12 Aug 2013 04:30:29 -0700 (PDT) Received: by 10.70.15.131 with HTTP; Mon, 12 Aug 2013 04:30:29 -0700 (PDT) In-Reply-To: References: <1376086561612-5717812.post@n5.nabble.com> Date: Mon, 12 Aug 2013 14:30:29 +0300 Message-ID: Subject: Re: Number of request per second. From: Adrian Speteanu To: JMeter Users List Content-Type: multipart/alternative; boundary=047d7b6d854c9a808604e3be73d2 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b6d854c9a808604e3be73d2 Content-Type: text/plain; charset=UTF-8 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 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 wrote: > > > Yep > > > > On 8/10/13, Shmuel Krakower wrote: > > > The report contains the throughput. Isn't that what you are looking > for? > > > On Aug 10, 2013 9:41 AM, "Deepak Goel" 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, hamepal@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-unsubscribe@jmeter.apache.org > > >> > For additional commands, e-mail: user-help@jmeter.apache.org > > >> > > > >> > > > >> > > >> > > >> -- > > >> Namaskara~Nalama~Guten Tag~Bonjour > > >> > > >> > > >> -- > > >> Keigu > > >> > > >> Deepak > > >> 7350012833 > > >> deicool@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-unsubscribe@jmeter.apache.org > > >> For additional commands, e-mail: user-help@jmeter.apache.org > > >> > > >> > > > > > > > > > -- > > Namaskara~Nalama~Guten Tag~Bonjour > > > > > > -- > > Keigu > > > > Deepak > > 7350012833 > > deicool@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-unsubscribe@jmeter.apache.org > > For additional commands, e-mail: user-help@jmeter.apache.org > > > > > --047d7b6d854c9a808604e3be73d2--