On 23 June 2011 13:57, Barrie Treloar <[email protected]> wrote: > On Thu, Jun 23, 2011 at 8:31 PM, sebb <[email protected]> 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? > > I think what he is saying is that if you have use a constant > throughput controller set to say 10, i.e. 1 every 6 seconds,
He did not mention Constant Throughput Controller (which anyway does not exist - I suspect you mean Constant Throughput Timer). The CTT can have problems generating the correct delays under some circumstances, but that is a different issue. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
