Load simulation

["Helfrich, Joe" <Jo...@GlobalCrossing.com>]

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
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?

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?

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.

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.

Thanks!

Joe Helfrich
QA Technician
Global Crossing Certification Lab
(303) 633 3102

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org

Re: Load simulation

[sebb <se...@gmail.com>]

On Fri, 3 Dec 2004 16:22:23 -0500, Helfrich, Joe
<jo...@globalcrossing.com> 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: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org