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]

Reply via email to