jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark McWhinney" <>
Subject RE: Memory / CPU usage
Date Wed, 03 Sep 2003 18:17:39 GMT
It would be interesting to see the difference.

I will send the jmx to you directly.

-----Original Message-----
From: peter lin [] 
Sent: Wednesday, September 03, 2003 10:32 AM
To: JMeter Users List
Subject: Re: Memory / CPU usage

if mark is willing to post a description of the test plan he used, I'm
willing to run OptimizeIt on JMeter 1.9.x to see anything obvious pop out. I
have a license of it, so running it is fairly simple.
peter wrote:
Despite what most people think, Java is not particularly slow. It is a
memory hog. If 20 
threads is causing your JVM to use 350MB memory, you may have to take steps
to reduce 
your memory usage. 

1. Smaller number of test elements. Every element is cloned for each thread.
If you have 
500 elements and 50 threads, that's 25,000 objects. A lot of people want to
make perfectly 
realistic test scripts, but I'd recommend going for something more abstract
and really 
reducing the number of different requests made.

2. Watch the listeners you use. Do not use a View Results Tree. If you have
problems, try using only the Aggregate Report and see if it helps. You can
always store the 
results and have a look at them in a different listener later.

I run 50-100 threads all the time without much difficulty. I'm not stressing
my CPU at all with 
that (P4 2Ghz), and I can stay under 200MB of RAM usage. I do sometimes run
into IO 
bottlenecks, however.

Incidentally, using GCJ is quite likely to give you a slower app, not a
faster one, and even if 
JMeter is one of those few apps that sees a 10-15% benefit from GCJ, you
will never notice 
that difference - particularly since JMeter spends so much of it's time
waiting on blocking IO 


On 3 Sep 2003 at 10:06, Duncan Frostick wrote:

> That's Java for you. As great as the portability and libs are, it's such 
> a painfully slow lang for performance tasks. I have a Solaris server 
> with 2GB of RAM and it can't do 100 threads without giving me stupidly 
> high response times (of close to an hour...) on some requests.
> Its a pity because JMeter is such a fantastically good tool when it 
> works, its just let down by performance issues. If you want to load test 
> at anything like a high load with JMeter you need several high powered 
> servers doing it in unision to spread the threads.
> I was trying to use the GCJ compiler - which claims to compile java 
> bytecode to machine code - to increase performance but I couldn't get it 
> working, that could be a possible performance boost. My general rule of 
> thumb is that for anything above 75 users JMeter/Java is too resource 
> hungry to give accurate results on my hardware.
> And now I'm trying high-loads, thats a problem. However, IBM have a 
> nifty if hard to configure tool called 'stress'. It's written in C so it 
> performs very well, just lacks a lot of JMeters great functionality. You 
> can find it online if you serach for IBM Web Performance Tools.
> Perhaps a port of JMeter to C++ should be considered? I know this would 
> involve doing a lot of painfully boring networking and threading code 
> but the performance gain would be huge.
> Cheers, Duncan
> Mark McWhinney wrote:
> >Hi all,
> >
> >I am a long time LoadRunner user but am new to JMeter. I am impressed
> >its functionality. It is a lot closer to LoadRunner than many of us in
> >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:

Michael Stover
Yahoo IM: mstover_ya
ICQ: 152975688
AIM: mstover777

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