tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Crowther <>
Subject RE: Apache httpd vs Tomcat static content performance
Date Mon, 18 May 2009 15:37:11 GMT
> From: Christopher Schultz []
> I suppose I could gauge each test so it would take (roughly) a certain
> amount of time (say, 10 minutes). At least then I'd know how long the
> entire battery would take :)

I think that's probably a better approach.

> Okay. My original test plan included concurrencies of 1, 2, 4, 8, and
> 16. I think I'll just do 1 and 16 and maybe another one if I get the
> time. Maybe I should just get a faster server :)

1, 4, 16 would be interesting - and if you run for fixed time rather than fixed number of
requests, you might be able to afford to do this.

> That's a good question... if the disk can't read the data any faster,
> than the server can't serve the bytes any faster (unless caching is
> being used, I suppose, but this is supposed to be
> out-of-the-box config).

You'd hope your underlying OS (Gentoo, I assume from your other message) would cache the file!

> Since this is a relatively old server (1500MHz 32-bit AMD Athlon), I'm
> surely being limited by just about everything except memory
> capacity (it
> doesn't take much memory to serve static content). I can easily get
> memory timing information, and I suspect my memory timing will
> significantly beat the throughput of the TCP stack (shared memory be
> damned). I can also benchmark my disk I suppose. Since I already have
> the transfer rates for the HTTP responses, I can simply see if the
> hardware is significantly faster than the server so rule-out any real
> hardware difficulties.

As a rough first cut, vmstat 5 and watch the numbers ;-).  iostat too, if you can.  If CPU
isn't pegged at 100% and the disk isn't at full capacity, that's an interesting result as
it implies the box has spare capacity and there's contention elsewhere - often lock contention,
as David Kerber has recently seen!

It just seems a shame to waste the opportunity to gather information about *what* the rate
limiter is, as well as at what point you get to the limit.

                - Peter

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

View raw message