jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark McWhinney" <>
Subject RE: Solution! (was: Memory / CPU usage)
Date Thu, 04 Sep 2003 17:39:27 GMT
Hi Peter,

The solution is to turn off image downloading for all but one thread which
gives the right about of load on the servers and still gives you end-user
transaction times.

I believe that the parsing of the HTML page is what causes the extra CPU
load in Jmeter not the extra processing of actually downloading the images.
I would need to crawl into the Jmeter code to confirm this.  If we are
right, then a custom parser could help.  This is mostly academic, though.
We can turn off image download altogether if we don't need end-user times or
use the hybrid approach that I described.


-----Original Message-----
From: peter lin [] 
Sent: Thursday, September 04, 2003 10:08 AM
To: JMeter Users List
Subject: RE: Solution! (was: Memory / CPU usage)

Hi mark,
did you have a particular solution in mind aside from turning off "load all
images?"  I tend to lots of heavy load testing, so I'm interested in
improving the performance of JMeter for really heavy loads.
Mike explained how HttpSampler gets the images. The first thing is JTidy
cleans the HTML. Then it gets the image nodes and tries to download it. One
possible approach is to by-pass JTidy and simply use a custom Sax Helper to
parse just the image nodes. Then the URL connection can simply read the
bytes without saving it and thereby reduce the memory consumption. I have no
idea if this will make any real difference, but just some random thoughts.

Mark McWhinney <> wrote:
Throwing hardware at a performance problem will help a bit but does not
solve the scalability problem. To be able to do a 1,000+ user load test, I
would need a large array of big machines. With the approach outlined below
plus more memory, I think that I can get there with a more modest budget.

-----Original Message-----
From: John Burgess [] 
Sent: Thursday, September 04, 2003 7:27 AM
To: JMeter Users List
Subject: Re: Solution! (was: Memory / CPU usage)

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" 
To: "'JMeter Users List'" 
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

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

-----Original Message-----
From: Mark McWhinney []
Sent: Wednesday, September 03, 2003 12:59 AM
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:
For additional commands, e-mail:

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

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

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

Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software

View raw message