On 23 June 2011 16:04, Kirk <[email protected]> wrote: > > On Jun 23, 2011, at 1:01 PM, sebb wrote: > >> On 23 June 2011 11:06, Kirk <[email protected]> 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? >> >> If so, for plain HTTP requests, IMO the model does agree with how >> users generally behave, because they won't generally click another >> link until the previous request has completed. >> >> For pages with embedded resources, modern browsers download these in >> parallel; this has been implemented and will be in the next JMeter >> release. >> [And it already has the Cache Manager] >> >> For most other protocols, the synchronous thread model is OK, as far as I >> know. > > If you want to know why LoadRoader or slikrunner... have little issue loading > to 1000s of users from a single instance, take a look at the internal > differences in threading model. > > Look, I've no interest in getting into a pissing match with you 'cos as I > mentioned before, what is here is no small feat to put together. That was not how I meant my response. 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. I'm just trying to establish why you say that the JMeter model can bottleneck. The idea would be to add this information to the JMeter wiki or bundled documentation in due course. > Kind regards, > Kirk > > > --------------------------------------------------------------------- > 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]
