>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 <[email protected]> wrote: > 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] > >
