You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by bu...@apache.org on 2009/09/22 15:00:23 UTC
DO NOT REPLY [Bug 47886] New: Use ThreadPool for threads rather than
create/start() with delay
https://issues.apache.org/bugzilla/show_bug.cgi?id=47886
Summary: Use ThreadPool for threads rather than create/start()
with delay
Product: JMeter
Version: unspecified
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: enhancement
Priority: P2
Component: Main
AssignedTo: jmeter-dev@jakarta.apache.org
ReportedBy: cflichel@novator.com
Created an attachment (id=24300)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=24300)
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 47886] Use ThreadPool for threads rather than
create/start() with delay
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47886
Flick <cf...@novator.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #24300|jmeter2.2threadpool.patch |jmeter2.3.2threadpool.patch
filename| |
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 47886] Use ThreadPool for threads rather than
create/start() with delay
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47886
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #1 from Sebb <se...@apache.org> 2009-09-22 07:21:47 PDT ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 47886] Use ThreadPool for threads rather than
create/start() with delay
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47886
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #7 from Sebb <se...@apache.org> 2009-09-22 16:20:55 PDT ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 47886] Use ThreadPool for threads rather than
create/start() with delay
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47886
Flick <cf...@novator.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #8 from Flick <cf...@novator.com> 2009-09-23 10:13:21 PDT ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 47886] Use ThreadPool for threads rather than
create/start() with delay
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47886
Flick <cf...@novator.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #2 from Flick <cf...@novator.com> 2009-09-22 08:03:09 PDT ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 47886] Use ThreadPool for threads rather than
create/start() with delay
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47886
Flick <cf...@novator.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #24300|0 |1
is obsolete| |
--- Comment #6 from Flick <cf...@novator.com> 2009-09-22 11:12:56 PDT ---
Created an attachment (id=24301)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=24301)
here is a patch for 2.3.4
Graceful shutdown maintained, although not sure that it works completely.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 47886] Use ThreadPool for threads rather than
create/start() with delay
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47886
--- Comment #5 from Sebb <se...@apache.org> 2009-09-22 08:59:13 PDT ---
In which case, just clear the context instead.
If you want to pursue this, please continue on the JMeter user list.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 47886] Use ThreadPool for threads rather than
create/start() with delay
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47886
--- Comment #3 from Sebb <se...@apache.org> 2009-09-22 08:46:42 PDT ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 47886] Use ThreadPool for threads rather than
create/start() with delay
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47886
--- Comment #4 from Flick <cf...@novator.com> 2009-09-22 08:53:39 PDT ---
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.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
DO NOT REPLY [Bug 47886] Use ThreadPool for threads rather than
create/start() with delay
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=47886
Flick <cf...@novator.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|unspecified |2.3.2
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org