jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Generate requests at specified time
Date Sun, 25 Sep 2011 13:56:51 GMT
On 25 September 2011 13:43, Jian-Ming Zheng <> wrote:
> Hi,
> Thanks for your reply.
> We do not want to model the Zipf-like distribution, but use it as an
> example of request patterns to test the Web server. We have designed
> some power management mechanism (i.e., dynamic voltage and frequency
> scaling approach) for used in Web server. We want to measure the
> performance of Web server (e.g., power consumption and response time)
> under several Web workloads, for example, Zipf-like distribution. In
> addition, we may generate other request patterns (not Zipf-like) and
> use them to test the server. So we want to control the requests issued
> by JMeter using a trace file.
> Yes, we can use the second solution and have already used it. We put
> all URLs into a file where the number of requests for a particular URL
> is based on Zipf-like distribution. Then, we use Constant Throughput
> Timer to control the number of requests sent per minute.
> However, it may be difficult to create a JMeter test plan if we want
> to use other request patterns that do not follow any distribution and
> are based on some user scenarios. That is the number of requests per
> second is particular, neither constant nor random. So it will be
> suitable for our case if JMeter can read a trace file to generate
> requests.
> JMeter is a powerful Web load testing tool but may not be suitable in
> our case. Please kindly let us know if other Web benchmark tools can
> read trace files to generate requests.
> Thanks for any replies.

You may be able to write your own implementation for the

That would probably be the most elegant solution.

A simpler solution might be to pre-process the input data for each
thread to include both the URL and the total elapsed time between the
start of the sample and the start of the next sample - let's call this
the readyTime, so the next sample should start at this sample start
time + readyTime.

The test thread then looks like

+ Sample URL
+ Wait until ready to start next sample.

It is easy enough to calculate the required pause time. The next
sample should start at:
sampleStartTime + readyTime
So the required pause is

sampleStartTime + readyTime - currentTime
or equally
readyTime - sample Elapsed time (assuming current time == end of
sample time, which should be approximately true)

Timers are processed before samplers, so it may be easier to use a
TestAction sampler or BSF/BSH Post-Processor.

For the TestAction sampler, the time can be calculated using one of
the scripting functions:

All the scripting functions have access to the variable:

sampleResult - previous SampleResult object (if any)

which has methods to obtain the start and elapsed times  For example

${readyTime} - sampleResult.getTime()

should work.

You might need to allow for the calculation returning a negative
number - i.e. the previous sample took too long.
If you want to log this, it would probably be simpler to use a BSF/BSH
Post-Processor to do the work.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message