In version 2.7 and earlier, JMeter created all the threads and associated data at the start of the test. Startup delay and ramp-up were implemented by each thread pausing as necessary.
This works well for tests where almost all threads are active for most of the run. But it's not good for tests with a large number of threads and where the ramp-up time is much longer than the time it takes to run a single thread. In such tests, the number of concurrently active threads is much lower than the total number of threads. So we've been experimenting with creating the per-thread resources at the time they are needed. After several iterations, we now have a development version of JMeter (*) that offers a "Delayed thread creation" option on the Thread Group GUI. When this is selected, the threads in a thread group are only created and started when they are due to run. The startup delay (if any) and ramp-up delay are now performed before the thread data is created. This means that the memory requirements are proportional to the number of concurrent active threads, rather than the total thread count. Provided that the active count does not grow too large, it should be possible to run tests with very large maximum thread count. If "Delayed thread creation" is not selected, JMeter behaves as before, i.e. all thread resouces are created at the start of a test. Note: this was originally implemented as an "On Demand ThreadGroup", but it was felt that "On Demand" could have implied that extra threads could be created during a test run. The implementation still requires the maximum thread count and ramp up to be defined in advance. (*) r1373042 and later for any developers who want to try this out. --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@jmeter.apache.org For additional commands, e-mail: user-h...@jmeter.apache.org