jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oren Benjamin" <oby1...@gmail.com>
Subject Re: Real traffic simulation and Access Log Sampler
Date Mon, 03 Mar 2008 06:10:57 GMT
Thanks for your response.  Since, my first post, I've taken JMeter for a
spin and was pleasantly surprised by how simple it was to set up a test plan
with Access Log Sampler to play back all the requests in my log.

I'm now ready to try and overcome the two hurdles we've discussed.  The
first involves the timing of the requests.  Based on your response ("the
sampler would need to keep track of the timestamps...") I take it the way to
go is to develop a custom Sampler, similar to Access Log Sampler, that also
handles the timestamps in the log.  Are you recommending to accomplish the
delay within the sampler itself or to create a custom Timer as well?

As for the threading, I'm not terribly concerned with simulating specific
users at the moment.  It would certainly be a nice feature down the road,
but for now, I'm more concerned with simply getting the requests
multi-threaded (as I'm completely new to JMeter and JMeter development, I
believe it's best to start small).

You wrote in your reply: "If the total number of different users is known in
advance, then one can just parcel out the samples to different threads."
How would this be accomplished?  Would I need to build a custom
ThreadGroup?  I haven't yet looked at the interplay between ThreadGroup and
Sampler.  Ignoring users for now, I'd like to divide all the requests among
a fixed number of threads.

As far as the timing is concerned, I would design it as follows.  Every
request (sample) is executed at the time indicated by its timestamp relative
to the start of the test.  If no thread is available at that time, it is
executed as soon as a thread becomes available.

As for sample logs, the Common Log Format (or indeed any log format) is fine
as I can always run my logs through a preprocessing script before loading
them into JMeter.  The important thing is that the entire request and the
corresponding timestamp are contained in the log entry.

Thanks again for your advice,

   -- Oren

On Sat, Mar 1, 2008 at 1:05 PM, sebb <sebbaz@gmail.com> wrote:

> On 29/02/2008, Oren Benjamin <oby1.cs@gmail.com> wrote:
> > For the purposes of stress testing and troubleshooting a large scale
> >  multi-tiered web application, we are looking to build a test
> environment in
> >  which we can recreate any scenario that occurs in production with very
> high
> >  fidelity.  To that end, we plan to "replay" the production server
> access
> >  logs by sending identical requests to the test environment at the same
> >  points in time (relative to the start of the test).  Furthermore, we
> would
> >  like the requests to be sent from multiple threads to simulate multiple
> >  users making the requests asynchronously.
> >
> >  I'm looking into the use of JMeter for our purposes.  From what I see
> it
> >  provides great reporting facilities, test abstractions, and a flexible
> >  architecture.  The Access Log Sampler seems like the logical starting
> point,
> >  but from reading the documentation and other threads on the mailing
> list, it
> >  looks like we're going to have to extend it quite a bit to meet or
> needs.
> >
> >  Here are the issues I've found so far:
> >
> >  1) Access Log Sampler ignores the time stamp of the log entries and the
> >  Timer mechanism is designed for "delays" as opposed to "alarms."  This
> would
> >  make it difficult to accurately simulate the timing of the requests in
> the
> >  log.
>
> This should be easy enough to implement.
>
> The sampler would need to keep track of the timestamps for each
> request it issues in a thread, and add a time delay as necessary.
>
> There would probably need to be some way of reporting if the desired
> start time has been exceeded.
>
> Also need to decide if the wait times should be relative to the
> previous sample or the start of the test. Or maybe make that optional?
>
> >  2) According to the ThreadGroup documentation, " each thread will
> execute
> >  the test plan in its entirety."  This is not we want, since we are
> looking
> >  to distribute the requests in the log among multiple threads.
>
> Yes, that is a problem currently.
>
> There are two aspects to this:
> - does the log contain sufficient information to be able to
> distinguish different users?
> - how to use this information in JMeter.
>
> It should be fairly easy to implement a filter to ignore all but one
> user/session when replaying a log.
>
> It gets a lot more tricky when multiple users are involved, as
> different users need different threads.
>
> If the total number of different users is known in advance, then one
> can just parcel out the samples to different threads. This may be
> sufficient for some cases.
>
> However, where there are too many different users to have a thread
> each, then JMeter needs to know when a given user has finished; it can
> then re-use the thread for another user. For a particular application,
> it may be possible to specify this, either as a specific entry in the
> log, or perhaps as a timeout since the last request.
>
> >  Any advice regarding whether JMeter is appropriate to this task and
> ideas
> >  related to the design of the test plan and any necessary
> plug-ins/extensions
> >  would be greatly appreciated.  From my limited investigation, it seems
> that
> >  this is a scenario that many groups are looking to implement, but no
> >  standard solution has been developed.
> >
>
> Specific use cases - with details of corresponding log file entries -
> might help to determine if there are standard patterns that JMeter
> could use.
>
> Perhaps it would be worth setting up a Wiki page with examples?
>
> >  Your feedback is much appreciated,
> >
> >
> >     -- Oren
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message