Bug 47886 - Use ThreadPool for threads rather than create/start() with delay
Summary: Use ThreadPool for threads rather than create/start() with delay
Status: RESOLVED DUPLICATE of bug 53418
Alias: None
Product: JMeter
Classification: Unclassified
Component: Main (show other bugs)
Version: 2.3.2
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: JMeter issues mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-22 06:00 UTC by Flick
Modified: 2012-09-28 14:05 UTC (History)
1 user (show)



Attachments
sample of the quick/dirty implementation i made of thread pool (11.75 KB, application/octet-stream)
2009-09-22 06:00 UTC, Flick
Details
here is a patch for 2.3.4 (13.64 KB, patch)
2009-09-22 11:12 UTC, Flick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Flick 2009-09-22 06:00:18 UTC
Created attachment 24300 [details]
sample of the quick/dirty implementation i made of thread pool

For long running tests for 1000s perhaps 10s of 1000s of users,
creating/starting that many threads is unreasonable and an unnecessary use of
resources when many of them sleep for extended periods of time.  Since java 1.5
incorporated many of the basic thread pools, they can easily be used.  Attached
is a sample of the quick hack that I did to use a scheduled thread pool.  It
works for my use, but may not work for all uses.
Comment 1 Sebb 2009-09-22 07:21:47 UTC
Thanks for the patch, though it seems to be made against JMeter 2.3.2 rather than the current SVN.

Also it disables graceful shutdown.

I can see that it would help for a test that has a large total number of threads where only a few are active at any one time, i.e. where there is a long ramp-up delay compared with the time it takes to run the tests in a thread. [But there are better ways to structure a test like that].

However, how does it help with a test where most/all of the threads are active concurrently? Does thread execution automatically switch between pool entries during a wait?

If so, there are quite a lot of samplers etc. that have been written assuming that a single instance will only be run by a single thread. I'm not sure how these will behave if they can be called from various different threads.
Comment 2 Flick 2009-09-22 08:03:09 UTC
The patch was just an example of what I hacked together to get our environment working.  In no way is it intended to be elegant, just a sample.  I am unfamiliar with the jmeter code base in its entirety and all the various samplers, but I think it is still reasonable to have something like this supported.  The thread pool i used doesn't fix the size at the configured amount, that's just how many are kept in the pool even when idle.  If the configured sampler had a high number of threads needing to execute simultaneously, the pool would create more.  It would still help my situation where i have 20K+ users executing over a 60 minute period resulting in only about 10-60 concurrent threads depending on response times.

In my sample, the state is maintained in the JMeterThread object, not the Thread, and the context still uses ThreadLocal since a given Thread from the thread pool is only used by one JMeterThread at a time.

Also, graceful shutdown could still be supported.
Comment 3 Sebb 2009-09-22 08:46:42 UTC
One alternative in your case is to re-use a single JMeter thread for multiple users in succession. I.e. wrap the login, samples, logout sequence in a loop controller.

You then set the total number of threads to the maximum concurrent users.

Which could be even cheaper than using a thread pool.

It may still be worth considering using a thread pool, but it's not clear if this would break any existing tests.
Comment 4 Flick 2009-09-22 08:53:39 UTC
Thanks for the suggestion, but it won't work in my case.  I need to simulate new sessions being created by Tomcat which is unrelated to login/logout.  It's related to a new user request, basically new context.
Comment 5 Sebb 2009-09-22 08:59:13 UTC
In which case, just clear the context instead.

If you want to pursue this, please continue on the JMeter user list.
Comment 6 Flick 2009-09-22 11:12:56 UTC
Created attachment 24301 [details]
here is a patch for 2.3.4

Graceful shutdown maintained, although not sure that it works completely.
Comment 7 Sebb 2009-09-22 16:20:55 UTC
Thanks for the replacement patch; it's easier to follow.

There are still some missing elements: for example, only the Scheduler delay is supported, the absolute start time is ignored, as are the end-time and duration. However these are easy to re-instate.

What I don't understand is why StandardJMeterEngine calls jmeterThread.initRun() which creates and populates the context for the JMeterThread. This seems wrong, as the context uses ThreadLocal, i.e. it will return the context for the engine thread, not the execution thread.
Comment 8 Flick 2009-09-23 10:13:21 UTC
It calls initRun (that i changed) to create a Context object and populate it with the necessary values.  When the thread actually starts, it takes the member context variable and then places it on the ThreadLocal for use.  This is because the JMeterThread only becomes the execution Thread at the point in time that the thread pool starts it.
Comment 9 Sebb 2012-09-28 14:05:41 UTC

*** This bug has been marked as a duplicate of bug 53418 ***