> 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 >