> Also, I'd be curious about the big disparity between the 16MiB files
> and the other 1MiB-32MiB files... It looks like all of them are
> relatively consistent at the KiB/sec rates you show - but suddenly
> there's a huge burst of speed on the 16MiB file (for httpd). So I'd
> be really curious to understand why the large disparity is evident
> there.

I believe Tomcat's default static memory cache size is 10MB, so you're going
to disk for each request at this point. This is configurable in the
Context<http://tomcat.apache.org/tomcat-6.0-doc/config/context.html>
element.
I'm not too familiar with httpd's default memory cache, would be worthwhile
to try and make them match. httpd also has a fancier cache removal
algorithms (LRU and GDSF).
Also fun to take a look at the free chapter at
http://oreilly.com/catalog/9780596101060/chapter/ch04.pdf - a benchmark with
smaller files and concurrent users.  This benchmark has the # of worker
threads match the # of concurrent users. But I've seen benchmarks where NIO
/ APR beat out the JIO connector when using fewer threads than the # of
concurrent requests - APR / NIO have ways to freeing worker threads and
going asynchronous for static content (check out the bottom of Advanced IO
and Tomcat <http://tomcat.apache.org/tomcat-6.0-doc/aio.html> ).

Benchmarking is fun but always take it with a grain of salt.


On Mon, May 18, 2009 at 9:15 AM, David kerber <dcker...@verizon.net> wrote:
>
> Peter Crowther wrote:
>
> ...
>>
>> 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!
>>
>>
>
> Indeed!  Getting rid of the extra locking took care of about 98% of the
issues, and changing to the Server jvm got me to over 99%.
>
> D
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Reply via email to