Gosh, I was about to dig into source code to setup some examples but I think you're explanation short-circuted that effort.
There is a different problem with large numbers of threads that I was writing up in a different email. I'll transfer to here and then continue. As follows: Iincreasing the number of threads would sort of increase the load but then you start hitting the wall in a number of other areas. For example, I have a benchmark that I've been running for years. This single threaded bench stresses the thread scheduler. The measured body of the bench should run in 1 second flat. Here are traditional results. Results get worse as you multi-thread. XP : 1900 ms Mac OSX 1100 ms Linux (just about every distro) : 1200ms Windows 7: 1010ms Solaris: 1100ms or 10100ms depending upon Kernel settings Anything OS virtualized hardware (Virtual Box, VMWare, Parallels) >2000ms (depending on virtualized OS) Sony has done something to Windows 7 so on better class hardware it runs in 1000ms. That said, hardware doesn't seem to matter. If I take a Dell box and run XP on it, I'll get 1900ms and if I run RedHat, 1200ms. Thread scheduling is getting better but... I was going to look in the code for calls to sleep(), currentTimeMilis() and other things that depend upon hardware/OS for specific performance details. These are outside of JMeter's control but like any framework, you can play into a platform's weaknesses or play away from them. Large numbers of threads currently plays into most platform's weaknesses. I'd like to think that common ground is that it's better if JMeter could produce a given load with fewer threads. That said, I don't expect JMeter to jump to an event base model *any* time soon.. that is completely unreasonable. However, I'll see if I can hack out a new ThreadGroup that reflects what I think can be done in the short term. Regards, Kirk On Jun 24, 2011, at 9:45 AM, Felix Frank wrote: > On 06/24/2011 01:37 AM, sebb wrote: >>> 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? >> > > I believe so. > > Many web applications reach a throughput plateau and cannot generate > more than X responses per time unit. > > If you double (triple,...) the number of threads, you have some Jmeter > instances with twice (three times,...) as many threads patiently waiting > for the server. The load as perceived by the system under test remains > roughly equal. > > (Please take my word for it. Same as Kirk, I suffered from this on > several occasions before. Nevertheless, Jmeter has proven time and again > to be both the most versatile and powerful load generator from the > arsenal I've yet tried.) > > If the system under test is a simplistic web application, I've used > timeouts to enable my threads to send more requests than the server will > readily respond to. Of course, the response data collected by such a > Thread Group is specious. So I'll have another, smaller Thread Group, > which acts patiently and collects performance and correctness data. > > All of this is a crude work-around of course. If Kirk has a model in > mind that will make such devices unnecessary, any positive developments > would be greatly appreciated. > > Regards, > Felix > > --------------------------------------------------------------------- > To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org > For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
