> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> 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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
