Return-Path: Delivered-To: apmail-jakarta-jmeter-user-archive@www.apache.org Received: (qmail 65112 invoked from network); 28 Jul 2010 07:14:26 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 28 Jul 2010 07:14:26 -0000 Received: (qmail 34688 invoked by uid 500); 28 Jul 2010 07:14:25 -0000 Delivered-To: apmail-jakarta-jmeter-user-archive@jakarta.apache.org Received: (qmail 34476 invoked by uid 500); 28 Jul 2010 07:14:23 -0000 Mailing-List: contact jmeter-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "JMeter Users List" Reply-To: "JMeter Users List" Delivered-To: mailing list jmeter-user@jakarta.apache.org Received: (qmail 34468 invoked by uid 99); 28 Jul 2010 07:14:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Jul 2010 07:14:22 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [81.17.212.138] (HELO mail.mpex.net) (81.17.212.138) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 28 Jul 2010 07:14:13 +0000 Received: (qmail 11449 invoked by uid 515); 28 Jul 2010 07:13:53 -0000 Received: from unknown (HELO ?192.168.1.212?) (ff@mpexnet.de@92.231.230.4) by mail-new with ESMTPA; 28 Jul 2010 07:13:53 -0000 Message-ID: <4C4FD8B0.50201@mpexnet.de> Date: Wed, 28 Jul 2010 09:13:52 +0200 From: Felix Frank User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4 MIME-Version: 1.0 To: JMeter Users List Subject: Re: constant rate testing (again) References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi Deepak, all of the below is true and quite accurate. The trouble with Jmeter is that it is too "patient", and even starting 1000 threads or more won't inject the same level of stress to on your server as a couple hundred real world users would. That's because Jmeter will gladly stand by for minutes at a time. Finding your throughput plateau is fine and all, but it would be nice if I could wreck the webserver the same way a swarm of real users will. Regards, Felix On 07/27/2010 10:57 PM, Deepak Goel wrote: > Hey > > Namaskara~Nalama~Guten Tag > > Just another though to this: > > If your load is reaching the servers, looks like the max load which your > server system can handle is that of one Jmeter server. When you add more > servers, the throughput will reduce as the max throughput of the system has > already been reached. After the max throughput has been reached, if you > increase the load, the throughput starts dropping as your server cannot > handle so many concurrent sessions simultaneously creating an overhead on > the execution of all the request in the system. > > For any system, you have to know what is the max throughput which it can > achieve beyond which the response time starts increasing exponentially. The > throughput then reaches a plateau, and if you increase the load further the > throughput would start decreasing and the system might even crash. > > I guess thats what happens in real world scenarios too. For example: In > normal shopping periods, the system is able to manage the real user load > with reasonable response times. During festive times, the system gets too > drained out with the incoming request, and the response time increases > exponentially. This causes a constant throughput and sometimes even the > system to crash. > > Did you try this option? > ***************************************************** > Or is all of this complicated setup == a >> large thread group + long ramp up period? > ***************************************************** > Deepak > --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: jmeter-user-help@jakarta.apache.org