jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Burgess" <j...@riskdecisions.com>
Subject Re: Solution! (was: Memory / CPU usage)
Date Thu, 04 Sep 2003 14:26:30 GMT
One point is that on a machine with 256M a heap size of 256M is probably too
big.  Memory's cheap at the moment - why not get at least another 256M and
preferably take it up to a gig

----- Original Message -----
From: "Mark McWhinney" <msm@portata.com>
To: "'JMeter Users List'" <jmeter-user@jakarta.apache.org>
Sent: Thursday, September 04, 2003 8:01 AM
Subject: Solution! (was: Memory / CPU usage)


I poked around some more then found and tested a solution to the memory and
CPU hog problem.

First some background observations:

1) Someone suggested upping the heap max from 64M to 128M.  I checked the
jmeter.bat file which was already set to the max heap to 256M.  I set it to
384M but it had no affect.  (I am on a 256M PC anyway.)

2) Once all threads started in the test plan, the number of threads and
process are constant as expected.  However, the number of handles and memory
increase steadily  (Memory increase I can understand, but why handles?)

3) Eliminating the listeners does not change the memory or CPU usage, so the
source of the problem is not the collection of a lot of stats.

4) Stopping the execution causes the CPU to drop from mostly 100% to around
0%.  The memory usage drop, however.  It does not release until JMeter is
exited.  Clear All clears the listener stats but does not release the
memory, which is consistent with observation #3.


Now for the interesting part.  I was running with no SSL, with keep-alive
turned on, and with retrieve all images turned on to best emulate real
usage.

I turned off image download for each page to see if there would be an
affect.  Big difference!  The CPU averaged about 20%.  As before the number
of processes and threads were steady once all the test plan treads were
started.  The number of handles and memory did steadily increase but at a
much slower rate.  As long as I keep the test execution time to a reasonable
period i.e. less than 20 minutes, I should be OK.

The problem is that with image download turned off, I am no longer emulating
the true end-user experience in terms of total response time per page.

Solution: Copy the thread group.  In first group, set the download images to
off for each page.  Set the thread group's number of threads to one less
than the number you want.  In the second group, set the download images to
on for every page.  Set the thread group's number of threads to one.

Between the two thread groups you will have the total number of threads that
you need to put load on the app server and database.  Use the listener(s) in
the second group to give you the end-user experience for the download times.
(For fun, put listeners on both groups and compare the response times.)

I have a sample test plan that demonstrates this solution against a public
demo site.  Let me know if you want a copy of it.  I will send it to you
directly.



-----Original Message-----
From: Mark McWhinney [mailto:msm@portata.com]
Sent: Wednesday, September 03, 2003 12:59 AM
To: jmeter-user@jakarta.apache.org
Subject: Memory / CPU usage


Hi all,

I am a long time LoadRunner user but am new to JMeter.  I am impressed with
its functionality.  It is a lot closer to LoadRunner than many of us in the
LoadRunner community realize.

I am going through the usual newbie issues but am actually reading the
manual and figuring it out.

I ran a test with one thread group with 30 threads that had six HTTP
requests with a 5 second wait time between each request.  I maxed out the
CPU at about 20 to 25 users on a 800 MHz Windows 2000 machine.  Memory
utilization was about 350 Mbytes.  Is that typical?  I am really going to
need 10 machines to do a 250 user load test or am I missing something?


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



Mime
View raw message