Hi Sebb, We've had this conversation before and I did some preliminary work to setup a different type of thread group but the couplings between the existing thread group and the model meant that an extensive refactoring would be involved. Since that involves a *lot* more than just a simple plugin...
So, the current implementation supports a closed system model meaning, rate of entry into the system equals rate of exit from the system. This is exactly what you want if you're load testing a call centre where the number of servers (operators) is fixed and gate entry into the system. However, I'm often simulating open systems which means I do not want rate of entry into the system to be controlled by the performance of the system (rate of exit). More over, those that attend my performance tuning seminars come to understand why this is an important aspect of getting your test environment right and test harness correctly setup as it can adversely affect the quality of your test which can and often does, change the results of the test. As an example, today I will show a group how to tune an application by a partner company. That application has a number of "performance problems" backed into it. If I use the traditional means of using JMeter I will find a different set of performance issues than if I load with a pattern that is similar that found in production. In other words, with this particular application, JMeter exposes "problems" that are artifacts of how it wants to inject load on a system. I can fix all of these problems and eventually I'll get to a point where I'll fix everything that needs to be fixed. That said, if I can coerce JMeter to load as an open system I'll get to the problems without having to fix the artifacts (the things that really don't need fixing). To coerce JMeter into being an open system requires one to use a large number of very short lived threads. So I may only have 400-500 active threads at any point in time but in order to achieve that load over a 1 or two hour test I may have to specify 10s of thousands of threads. Since all of the threads are created up front, this simply doesn't work. You might ask why not just specify 400-500 threads and loop over them? in theory you'd think it would work but as you tune the system and the performance characteristics change. Going back to the baked application, before I start tuning, the active user count is several thousand. In other words, the tuned system is better able to clear users out and that changes the performance profile in a way that hard to emulate with the current looping behaviour. Using a setting of looping 400 or so threads isn't adequate for the initial load tests as the test harness will become thread starved and that releases pressure on the server which in turn changes the performance profile. With all due respect to the wonderful work that everyone on the project has done, it is my opinion that the one user == one thread is a design mistake that has a huge impact on both the usability of the tool and the quality of the results one can achieve when using it. IMHO, moving to an thread pool/event heap based model would be an enormous improvement over the current implementation. Regards, Kirk On 2012-06-13, at 1:02 AM, sebb wrote: > On 12 June 2012 22:57, Kirk Pepperdine <kirk.pepperd...@gmail.com> wrote: >> >> On 2012-06-13, at 12:54 AM, sebb wrote: >> >>> On 12 June 2012 22:06, Kirk Pepperdine <kirk.pepperd...@gmail.com> wrote: >>>> Hi, >>>> >>>> I figured thread pooling would be revolutionary so I wasn't suggesting >>>> that. I would be very useful just delay the creation of a thread until it >>>> was asked for. >>> >>> Not sure I understand how it would help to delay the thread creation, >>> except perhaps for the case where the first threads have finished >>> processing by the time the last threads start running samples. >> >> Bingo!!! ;-) > > So what percentage of use cases need to follow this model? > > Most of the JMeter testing I have done was long running tests where > all threads were active for most of the run. > >> Kirk >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org >> For additional commands, e-mail: user-h...@jmeter.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org > For additional commands, e-mail: user-h...@jmeter.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org
