On 24 June 2011 00:12, Kirk <[email protected]> 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 threads and you want to simulate Y requests >> per second (the most common use case is a background load while you test >> adding some new functionality). If the server starts responding slower then >> each Jmeter thread will wait longer and you might run into a situation where >> you cannot simulate Y requests per second since there are no threads >> available to make new request (hence I guess 'thread starvation' but the >> term means something else to me) to keep up the Y requests/second > > 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 to understand, more difficult to implement but > open by design and less likely to self throttle.
What I would do here is increase the number of threads. This will allow more requests to be generated, at least until the number of threads / memory use starts to be an issue. At which point, add another JMeter client to share the load. Or am I overlooking something? > Regards, > Kirk > >> >> regards >> deepak >> >> >> >> On Thu, Jun 23, 2011 at 3:34 PM, Barrie Treloar <[email protected]> wrote: >> >>> On Fri, Jun 24, 2011 at 2:50 AM, Kirk <[email protected]> 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 >>> of the overall system (thread starvation in JMeter) can result a load >>> pattern that doesn't properly expose an underlying bottleneck. This is what >>> I've run into in a couple of accounts. Problem in these cases is that >>> developers are looking into the application and not seeing where the real >>> problem is. >>> >>> I'm newish to the list, so I haven't seen this discussion before. >>> Can you elaborate some more about why the Thread starvation occurs? >>> >>>> The other issue is that it's hard to setup a JMeter script so that it >>> sustains an expected workload on a server. This is why I've suggested, >>> teach, demonstrate and continue to use ThreadGroup in a way that you >>> yourself called "bizarre". Yet using that model I'm able to simulation 1000s >>> of users in a single JMeter instance all doing the right thing (or as much >>> of a right thing as the current HTTP samplers allow for). And yup, I've got >>> a ThreadGroup replacement sketched out on my whiteboard, now to find some >>> cycles to make it real. I think it should eliminate the need for the >>> constant throughput timer (but, who knows ;-)). >>> >>> And same with this one, what do you do differently with ThreadGroups and >>> why? >>> >>>> Also, it would be really really nice to normalize the priority behavior >>> of some of the components such as the timers. IME, how timers work is 1) not >>> intuitive and hence difficult for newbies to get right and 2) creates extra >>> work trying to get the timers to behave (i.e, the test action or simple >>> controller hack around). >>> >>> I'm definitely interested in this, what specifically about priorities. >>> I'm in the camp of hacking the timers to get it to behave "correctly". >>> At least its better than the perl script we've currently got that >>> calculates a bunch of values to try to set ramp up/throughput times to >>> get what we are looking for. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
