Jeremy Arnold wrote:
[...] But since most threads are sleeping most of the time, perhaps we can come up with some sort of thread pool, so that a large number of JMeter "threads" (perhaps better to call them "users" in this case) could be handled by a smaller number of JVM threads. It could be a bit tricky to ensure that we have the right number of JVM threads to handle the JMeter users, and that samples are executed when they are supposed to. But it seems like there could be potential.
I usually prefer to leave the low-level stuff at the low-level layer: the JVM makes should care about threading efficiency (actually it looks like they do, see http://developer.java.sun.com/developer/technicalArticles/JavaTechandLinux/RedHat/ ).
When I read Jordi's message, I thought he was referring to have a system dedicated to performance regression tests, so that we can see the effects of changes to JMeter on its performance. For example, if we start messing with a thread pool, we would need to be certain that we weren't impacting the results (at least not negatively -- but even if we made an improvement it would be good to document that).
Yes, that's exactly what I meant. Thanks for the clarification.
Seems like we've got some high hopes for JMeter 2.0...even in just a short discussion -- I'm looking forward to getting started on it.
Jeremy http://xirr.com/~jeremy_a
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Salut,
Jordi.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
