jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: Load simulation
Date Fri, 03 Dec 2004 23:20:52 GMT
On Fri, 3 Dec 2004 16:22:23 -0500, Helfrich, Joe
<> wrote:
> These questions are equal parts test plan construction and technical
> questions about jmeter (and could possibly evolve into questions about
> apache and tomcat); if I'm not in the right place, please point me
> hence.
> We're trying to simulate high load on a login page: specifically, in
> this case, 450 page requests in a 300 second (five minute) window.  Not

I make that 1.5 requests per second 

I would have thought a single JMeter instance would be enough to
generate that load, especially if run in non-GUI mode.

> seeing an easy way to guarantee a certain number of requests in a given
> period, I went for the brute force method; designing the program to
> execute 150 threads in a 300 second ramp up, one loop.  The test bed was
> three computers--mine as control and tester, two running jmeter in
> server mode--all running Windows XP SP1, from various points in our
> corporate intranet.  The test plan was fairly simple:
> Thread Group
>         HTTP Request (to get XML response)
>                 Response Assertion (to verify receipt of complete
> response)
>                 Aggregate Report
>         HTTP Request Defaults
> Cookie Manager was explicitly excluded to force generation of cookie on
> all requests, as each was supposed to represent a separate unique user
> log in.
> Questions:
> 1. Is there a more elegant way of meeting our traffic goals than the
> mass generation of threads?

The constant throughput timer would be suitable here - you just need
to scale it for the number of active threads.

> 2. As an extension to the above, I'd like introduce a Gaussian Random
> timer, so that all the requests aren't coming in threes at regularly
> spaced intervals.  But with the addition of the timer delay, how do I
> still make sure that all requests are completed in five minutes?

If combined with the Constant Throughput Timer, it should work.

> 3. When testing against our certification environment (a single box
> running both Apache and Tomcat) the response was predictably slow, but I
> got 450 successful requests.  When we moved to our production
> environment (traffic is routed by an Alteon to a second box running
> Apache, which then passes the request to a third running Tomcat, which
> processes the request) early responses came back very quickly, but as
> the test went on, response time deteriorated quickly, and Apache and
> Tomcat performance with it.  A shell script that generated a similar
> level of load (using four threads that waited for a response before
> sending the next request) saw some slight performance degradation in the
> servers, but they were able to recover and process all the requests.  I
> realize this is probably a configuration issue on the server side, but
> thought I'd see if anyone had any ideas.

No idea, sorry.

> 4. I don't want to call it a bug yet, but I want to make sure that this
> isn't a known issue with jmeter before I do more investigation.  When we
> were seeing serious performance hits on the servers, I tried to Remote
> Stop All, and when the system didn't respond quickly to that request, I
> went to Remote Exit All.  The remote clients did exit, but Remote Stop
> was still enabled in the menu, and the GUI still indicated that threads
> were running with the green run light still on.  I'd had to manually
> start rmiregistry, and am not all that confident that I had my classpath
> correct on the remote servers, so it's very possible this is a problem
> with my installation rather then jmeter.  If there's no known issue,
> I'll try to resolve those problems and see if the symptoms persist.

I rarely use JMeter in anything but non-GUI mode for actual
performance tests, so I dunno if this is a known problem.

However, I do know that:
- there must be no spaces in the JMeter installation directory path names
- identical versions of JMeter need to be installed on all the systems

You might want to check that the servers behave OK if given a very
short and simple test.


I suggest you try creating a test plan using the above suggestions,
but substitute the JavaTest sampler for the HTTP Sampler. You can then
see how JMeter handles the load, and whether the desired transaction
rate is produced.

You could then try introducing the HTTP Sampler, but request a simple
small page initially.

And so on.

I doubt that you will need to use multiple JMeter instances to create
the load you have specified.

> Thanks!
> Joe Helfrich
> QA Technician
> Global Crossing Certification Lab
> (303) 633 3102
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message