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 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 server when they really >>>> needed to be looking at what was coming behind them. IMHO, a thread per >>>> user is an easy model to grasp but is much easier to set yourself up for >>>> failure. Case in point, and earlier suggestion that if the response times >>>> are greater than the desired rate of arrival at the server, the throughput >>>> will drop 'cos JMeter will simply not have enough threads to trigger the >>>> request. Hence, the bottleneck in the system will be JMeter. While some >>>> might argue that this is sill ok (and in a number of cases it's not >>>> harmful), an event based model would be much more scalable and less prone >>>> to this type of testing failure.. artificial throttling of throughput. >>> >>> If I understand you correctly, what you are saying is that the maximum >>> throughput for a single JMeter thread is limited by the response time >>> of the server, because JMeter waits for the sample to complete before >>> issuing the next request. >>> >>> Have I got it right? >> >> Judging by your response I don't think that my message was clear. If I put a >> single usage pattern (pattern that a user executes to complete a multi-step >> business transaction) into a single thread group and then execute that >> thread group then there *is* a real possibility of JMeter/test harness >> thread starvation. > > Now I'm more confused. > What causes the starvation if it is not the synchronous behaviour of > JMeter threads? Yup, thats it, the synchronous behavior of JMeter threads. > > That was not how I meant my response. Understood, I just didn't want to be seen as ragging on the tool or the good work that people have done with this tool. > I'm sure there are ways in which JMeter can be improved, and ways in > which other tools are better. > My comments about current JMeter design were just meant as > explanation, nothing more. ok, this is what I meant about a pissing match. I'm not interested in comparing tooling, just sorting out how this tool can be improved. 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. 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 ;-)). 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). Regards, Kirk --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
