On 06/24/2011 01:37 AM, sebb wrote:
It means, keep up the Y requests / time unit... and you cannot do that with
JMeter or any other load test harness with a similar threading model. This
threading model is easy to write, easy to understand but self throttling.
Event base models are harder
Gosh, I was about to dig into source code to setup some examples but I think
you're explanation short-circuted that effort.
There is a different problem with large numbers of threads that I was writing
up in a different email. I'll transfer to here and then continue. As follows:
Iincreasing
On 06/22/2011 06:13 PM, jsheth wrote:
Also, if I run jmeter with 200 users, do I have to tweak anything in
apache/tomcat on webserver so that it can handle 200 users? What is the
default # of users the apache/tomcat can handle at once?
Usually you test the other way around: You raise the
On Thu, Jun 23, 2011 at 8:31 PM, sebb seb...@gmail.com wrote:
On 23 June 2011 11:06, Kirk kirk.pepperd...@gmail.com wrote:
One has to really be careful with JMeter's threading model. It has the
potential to act as the bottleneck in your load test. I've seen a few teams
chasing all kinds of
On 23 June 2011 13:57, Barrie Treloar baerr...@gmail.com wrote:
On Thu, Jun 23, 2011 at 8:31 PM, sebb seb...@gmail.com wrote:
On 23 June 2011 11:06, Kirk kirk.pepperd...@gmail.com wrote:
One has to really be careful with JMeter's threading model. It has the
potential to act as the bottleneck
HI,
Do not have a Throughput Controller in my test script
From: sebb-2-2 [via JMeter]
[mailto:ml-node+4517382-1579059076-45...@n5.nabble.com]
Sent: Thursday, June 23, 2011 9:10 AM
To: Jeegnesh Sheth
Subject: Re: determining ramp-up period
On 23 June 2011 13:57, Barrie Treloar [hidden
On Jun 23, 2011, at 1:01 PM, sebb wrote:
On 23 June 2011 11:06, Kirk kirk.pepperd...@gmail.com wrote:
One has to really be careful with JMeter's threading model. It has the
potential to act as the bottleneck in your load test. I've seen a few teams
chasing all kinds of things in the app
On 23 June 2011 16:04, Kirk kirk.pepperd...@gmail.com wrote:
On Jun 23, 2011, at 1:01 PM, sebb wrote:
On 23 June 2011 11:06, Kirk kirk.pepperd...@gmail.com wrote:
One has to really be careful with JMeter's threading model. It has the
potential to act as the bottleneck in your load test.
I'm just trying to establish why you say that the JMeter model can
bottleneck.
Yes this sounds like interesting stuff.
On Thu, Jun 23, 2011 at 9:34 AM, sebb seb...@gmail.com wrote:
On 23 June 2011 16:04, Kirk kirk.pepperd...@gmail.com wrote:
On Jun 23, 2011, at 1:01 PM, sebb wrote:
On
Hi Sebb,
Happy to engage in a technical discussion.
On Jun 23, 2011, at 6:34 PM, sebb wrote:
On 23 June 2011 16:04, Kirk kirk.pepperd...@gmail.com wrote:
On Jun 23, 2011, at 1:01 PM, sebb wrote:
On 23 June 2011 11:06, Kirk kirk.pepperd...@gmail.com wrote:
One has to really be careful
On Fri, Jun 24, 2011 at 2:50 AM, Kirk kirk.pepperd...@gmail.com wrote:
If I'm expecting an incoming tx rate of 200 requests per second and JMeter
doesn't have the threads to sustain it.. then I would consider JMeter to be a
bottleneck in the test. This is because the artificially throttling
Can you elaborate some more about why the Thread starvation occurs?
Im not sure if the terminology accurately describes the issue . But lets say
you run a test with X number of threads and you want to simulate Y requests
per second (the most common use case is a background load while you test
Hi Barrie,
On Jun 24, 2011, at 12:34 AM, Barrie Treloar wrote:
On Fri, Jun 24, 2011 at 2:50 AM, Kirk kirk.pepperd...@gmail.com wrote:
If I'm expecting an incoming tx rate of 200 requests per second and JMeter
doesn't have the threads to sustain it.. then I would consider JMeter to be
a
On Jun 24, 2011, at 12:53 AM, Deepak Shetty wrote:
Can you elaborate some more about why the Thread starvation occurs?
Im not sure if the terminology accurately describes the issue . But lets say
you run a test with X number of threads and you want to simulate Y requests
per second (the most
+4519338-940910384-45...@n5.nabble.com]
Sent: Thursday, June 23, 2011 7:08 PM
To: Jeegnesh Sheth
Subject: Re: determining ramp-up period
Hi Barrie,
On Jun 24, 2011, at 12:34 AM, Barrie Treloar wrote:
On Fri, Jun 24, 2011 at 2:50 AM, Kirk [hidden email] wrote:
If I'm expecting an incoming tx
On 24 June 2011 00:12, Kirk kirk.pepperd...@gmail.com wrote:
On Jun 24, 2011, at 12:53 AM, Deepak Shetty wrote:
Can you elaborate some more about why the Thread starvation occurs?
Im not sure if the terminology accurately describes the issue . But lets say
you run a test with X number of
was it that you did to show issues wrt connection pool? Is your demo
available on a public forum?
Thank You
Jigi
From: kirk-17 [via JMeter]
[mailto:ml-node+4519338-940910384-45...@n5.nabble.com]
Sent: Thursday, June 23, 2011 7:08 PM
To: Jeegnesh Sheth
Subject: Re: determining ramp-up period
-45...@n5.nabble.com]
Sent: Wednesday, June 22, 2011 3:54 AM
To: Jeegnesh Sheth
Subject: Re: determining ramp-up period
On 06/22/2011 03:21 AM, jsheth wrote:
ERROR - jmeter.engine.StandardJMeterEngine: Uncaught exception:
java.lang.OutOfMemoryError: GC overhead limit exceeded
Your threads
On 06/22/2011 03:30 PM, jsheth wrote:
2. Aggregate report
3. View results tree
Deactivating these will most likely help your memory problems. Only
enable them if you really need them (i.e. the View Results Tree for
debugging, the aggregate report isn't really necessary at any
Dear Frank,
What is the best way to save results to CSV if I run in silent mode?
From: Felix Frank-2 [via JMeter]
[mailto:ml-node+4514058-1648290135-45...@n5.nabble.com]
Sent: Wednesday, June 22, 2011 9:38 AM
To: Jeegnesh Sheth
Subject: Re: determining ramp-up period
On 06/22/2011 03:30
: Wednesday, June 22, 2011 9:38 AM
To: Jeegnesh Sheth
Subject: Re: determining ramp-up period
On 06/22/2011 03:30 PM, jsheth wrote:
2. Aggregate report
3. View results tree
Deactivating these will most likely help your memory problems. Only
enable them if you really need them
: Re: determining ramp-up period
On 06/22/2011 03:30 PM, jsheth wrote:
2. Aggregate report
3. View results tree
Deactivating these will most likely help your memory problems. Only
enable them if you really need them (i.e. the View Results Tree for
debugging, the aggregate
What happened when you experimented with other ramp up periods?
--
View this message in context:
http://jmeter.512774.n5.nabble.com/determining-ramp-up-period-tp4512401p4512425.html
Sent from the JMeter - User mailing list archive at Nabble.com.
: determining ramp-up period
What happened when you experimented with other ramp up periods?
If you reply to this email, your message will be added to the discussion
below:
http://jmeter.512774.n5.nabble.com/determining-ramp-up-period-tp4512401p
4512425.html
On Wed, Jun 22, 2011 at 9:38 AM, jsheth jsh...@src-solutions.com wrote:
I would get 500 response from the web code for random threads. some
threads would finish while others would fail on certain pages
Chances are this is showing you peak load issues with your web server
- which you didn't
On Wed, Jun 22, 2011 at 10:31 AM, jsheth jsh...@src-solutions.com wrote:
So for 200 threads I should set my ramp up time to be 6000?
Ramp up time = 6000 seconds.
This will start a new thread, on average, every 6000/200 = 30 seconds
where all threads will be running after 6000/60 = 100 minutes
Also see
http://jakarta.apache.org/jmeter/usermanual/test_plan.html#thread_group
and
http://www.google.com/search?q=jmeter+calculate+ramp+up+time
-
To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org
For
From: Barrie Treloar [via JMeter]
[mailto:ml-node+4512540-133413972-45...@n5.nabble.com]
Sent: Tuesday, June 21, 2011 9:17 PM
To: Jeegnesh Sheth
Subject: Re: determining ramp-up period
On Wed, Jun 22, 2011 at 10:31 AM, jsheth [hidden email] wrote:
So for 200 threads I should set my ramp
28 matches
Mail list logo
