tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Load testing, benchmarking, and tuning
Date Tue, 07 Aug 2007 14:25:04 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

rhull,

rhull wrote:
> I've got Tomcat (5.0) running on Linux with JVM 1.5.0_12, with a pretty thin
> servlet.  I'm fairly new to benchmarking/load testing with Tomcat, and some
> of my numbers seem odd.

They always do when you get started ;)

> Load testing with WAPT from a Windows box across the internet to Tomcat
> running on the Linux machine, I'm only seeing something around 15
> transactions per second.  This seems like an unlikely low number to me.

How many hops away? What type of Internet connection? If you're testing
from home, then your local connection probably sucks compared to the
server's connection to the Internet. I usually try to load test over a
LAN or short hops over a WAN. That way, I can see what the app can
handle if my server is being swamped by machines that are topologically
diverse, yet all coming through my server's Internet connection.

> When I run load testing local to the Linux box using Siege, I'm seeing
> around 600 transactions per second.  This seems like an unrealistically
> large number to me, and I assume the TCP/IP loopback is taking a lot of
> network-related effort out of the equation.

Yup. You're basically taking network lag totally out of the equation.

> I've tried fiddling with the server.xml thread settings, but it didn't seem
> to have much affect on my transactions per second.

If you really do have a "pretty thin" servlet, then your transaction
time is probably being dominated by network traffic.

> Running "top" on the box while the Siege load testing was occurring gave me
> this information:

>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 29503 tomcat    25   0 1356m 200m  13m S  711  2.5  41:05.61 java

Holy crap, 711% of the CPU? That's amazing!

Seriously, though, 'top' isn't a serious load-testing tool by any means.
If anything, use something like 'sar'. Top basically tells you what's
running /right now/ and gives you a myopic view of the timings, etc.

> There's obviously some load on the box (though not necessarily CPU), but it
> certainly doesn't seem to be maxed out close to 100% of any resources.

> Cpu(s): 19.2% us, 71.0% sy,  0.0% ni,  9.8% id,  0.0% wa,  0.0% hi,
0.0% si

71% system call usage. That seems kind of high. Then again, if your
servlet is doing almost nothing, then you're living inside of the TCP/IP
library the whole time, which probably uses many system calls.

> So, I'm kind of stuck:
> A) How can I determine what kind of ballpark, realistic transaction
> throughput I *should* be expecting with my particular combination of
> hardware and software?

Where is your server, and what machines do you control that are
topologically close to it?

> B) How can I determine what the bottlenecking factor(s) is(are) on the
> throughput?

You should get a good measurement, first. Don't try to fix something you
haven't verified is broken, yet.

Also don't forget that a local load test isn't worthless. As long as you
know you are comparing apples-to-apples, you can do local load tests to
tweak your code. Your code doesn't run any differently when accessed
locally or remotely. So, if you suspect a bottleneck in your code, you
can use local tests to try to remedy it; if your tests show that your
code is faster, it's still valid.

Just don't use local load testing numbers to guess the number of remote
users you can support ;)

- -chris

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGuIDA9CaO5/Lv0PARAjPUAJ9FKPaigU6Or66nfoHsQnih4K5rawCdGR9S
vV9or8NKqvvLjqfLXxzbuBs=
=R0nH
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message