jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Helfrich, Joe" <Joe.Helfr...@GlobalCrossing.com>
Subject Load simulation
Date Fri, 03 Dec 2004 21:22:23 GMT
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


Mime
View raw message