Re: JMeterThread initialization (additional comments)
Hi, Thank you for your comments and advices. I implemented a barrier synchronization for JMeterThreads. Could you check out http://issues.apache.org/bugzilla/show_bug.cgi?id=29708+ ? May I have your comments about this feature? Thank you. - Masashi Takeichi On Wed, 16 Jun 2004 08:30:41 -0400 Michael Stover [EMAIL PROTECTED] wrote: I had to go back to the problem, but it seems to me, his problem would be solved if all the threads were cloned prior to starting the first JMeterThread. That would be a very minimal change to just the Engine code. -Mike On Wed, 2004-06-16 at 05:47, BAZLEY, Sebastian wrote: If this were to be adopted, it would have to be optional, and a way would have to be found that did not involve unconditionally waiting for a set time (e.g. use a barrier technique as described in Java Threads pub. by O'Reilly). There will always be startup overheads. One way to minimize these is to ensure that the main tests run for much longer than the startup. e.g. if startup takes 5 minutes, then run for several hours. I'm not saying that this enhancement would not be useful in some cases, but it should not be at the expense of tests that don't require it. S. P.S. By the way, the best way to provide patches etc is to raise a Bugzilla issue (in this case an enhancement); files can then be attached to the issue. That way, the file contents don't get mangled, and the e-mail messages are smaller (not that this patch was big). -Original Message- From: Masashi Takeichi [mailto:[EMAIL PROTECTED] Sent: 16 June 2004 07:23 To: [EMAIL PROTECTED] Subject: Re: JMeterThread initialization (additional comments) Hi I'll propose a solution for 'JMeterThread initialization' issue. This will enable all the JMeterThread to start at the same time as possible. As a result, rampup timings will become more accurate. My proposal consists of the following changes 1) [JMeterThread] All the JMeterThreads wait to be notified by JMeterEngine, after they are ready. 2) [StandarJMeterEngine] JMeterEngine notifies JMeterThreads all together. [snip solution relying on waiting for 5 seconds] ___ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Stover [EMAIL PROTECTED] Apache Software Foundation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JMeterThread initialization (additional comments)
Hi I'll propose a solution for 'JMeterThread initialization' issue. This will enable all the JMeterThread to start at the same time as possible. As a result, rampup timings will become more accurate. My proposal consists of the following changes 1) [JMeterThread] All the JMeterThreads wait to be notified by JMeterEngine, after they are ready. 2) [StandarJMeterEngine] JMeterEngine notifies JMeterThreads all together. Attachments are patch files for demonstrating this solution's effect. [CAUTION] src version : 2.0.1 These patches are very simple implementations, just for demonstrating. So they have some problems that must be fixed. Please let me hear your comments. Thank you. - Masashi Takeichi [EMAIL PROTECTED] On Mon, 14 Jun 2004 21:17:15 +0900 Masashi Takeichi [EMAIL PROTECTED] wrote: Hello May I ask you a question about StandardJMeterEngine? I made my custom Sampler and plugged into JMeter. Its constructor accesses some files to configure itself. And it takes about 500 milliseconds. I thought that the processing cost doesn't affect a performance of JMeter. But actually, rampup timings were later than what were expected. In StandardJMeterEngine.run() method [316-344], JMeterThreads are created, configured and started in turn. So the longer time it takes to construct and configure, the later the rampup timings are. I think that this problem is solvable in the following change of StandardJMeterEngine. After all the JMeterThreads for a TestPlan are ready, StandardJMeterEngine call Thread.start() for each JMeterThread. Can I get some feedback on this? Thank you. - Masashi Takeichi [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JMeterThread initialization (additional comments)
If this were to be adopted, it would have to be optional, and a way would have to be found that did not involve unconditionally waiting for a set time (e.g. use a barrier technique as described in Java Threads pub. by O'Reilly). There will always be startup overheads. One way to minimize these is to ensure that the main tests run for much longer than the startup. e.g. if startup takes 5 minutes, then run for several hours. I'm not saying that this enhancement would not be useful in some cases, but it should not be at the expense of tests that don't require it. S. P.S. By the way, the best way to provide patches etc is to raise a Bugzilla issue (in this case an enhancement); files can then be attached to the issue. That way, the file contents don't get mangled, and the e-mail messages are smaller (not that this patch was big). -Original Message- From: Masashi Takeichi [mailto:[EMAIL PROTECTED] Sent: 16 June 2004 07:23 To: [EMAIL PROTECTED] Subject: Re: JMeterThread initialization (additional comments) Hi I'll propose a solution for 'JMeterThread initialization' issue. This will enable all the JMeterThread to start at the same time as possible. As a result, rampup timings will become more accurate. My proposal consists of the following changes 1) [JMeterThread] All the JMeterThreads wait to be notified by JMeterEngine, after they are ready. 2) [StandarJMeterEngine] JMeterEngine notifies JMeterThreads all together. [snip solution relying on waiting for 5 seconds] ___ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JMeterThread initialization (additional comments)
I had to go back to the problem, but it seems to me, his problem would be solved if all the threads were cloned prior to starting the first JMeterThread. That would be a very minimal change to just the Engine code. -Mike On Wed, 2004-06-16 at 05:47, BAZLEY, Sebastian wrote: If this were to be adopted, it would have to be optional, and a way would have to be found that did not involve unconditionally waiting for a set time (e.g. use a barrier technique as described in Java Threads pub. by O'Reilly). There will always be startup overheads. One way to minimize these is to ensure that the main tests run for much longer than the startup. e.g. if startup takes 5 minutes, then run for several hours. I'm not saying that this enhancement would not be useful in some cases, but it should not be at the expense of tests that don't require it. S. P.S. By the way, the best way to provide patches etc is to raise a Bugzilla issue (in this case an enhancement); files can then be attached to the issue. That way, the file contents don't get mangled, and the e-mail messages are smaller (not that this patch was big). -Original Message- From: Masashi Takeichi [mailto:[EMAIL PROTECTED] Sent: 16 June 2004 07:23 To: [EMAIL PROTECTED] Subject: Re: JMeterThread initialization (additional comments) Hi I'll propose a solution for 'JMeterThread initialization' issue. This will enable all the JMeterThread to start at the same time as possible. As a result, rampup timings will become more accurate. My proposal consists of the following changes 1) [JMeterThread] All the JMeterThreads wait to be notified by JMeterEngine, after they are ready. 2) [StandarJMeterEngine] JMeterEngine notifies JMeterThreads all together. [snip solution relying on waiting for 5 seconds] ___ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael Stover [EMAIL PROTECTED] Apache Software Foundation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
