if I have time this weekend, I'll try to run the same benchmarks on the latest code.
is it included in the nightly build? if not, can someone post a build for me to benchmark on my system? peter On 4/14/05, Remy Maucherat <[EMAIL PROTECTED]> wrote: > Hi, > > This has been hinted for a while ;) The purpose of this email is to > propose using APR (Apache Portable Runtime) as the network IO used by > Tomcat, instead of the JVM's IO. > > This will provide the following benefits (some small, others more > significant): > - zero GC IO API (APR is not object based) > - flexible handling of socket reads/writes using pollers and non blocking IO > - sendfile support > > Which will allow: > - better scalability when using HTTP/1.1 keepalive, by eliminating the > need for tying a thread blocked on an IO read (one or more (one on Unix, > plenty on Windows) pollers will be used instead); this will allow > certain single machine servers which couldn't use keealive in order to > limit the amount of threads (to be able to have more simultaneous users) > to benefit from the (large) performance benefits of keepalive > - better performance and easier configuration when using AJP: one > of the issues of AJP at the moment is that the number of AJP processors > in Tomcat must be equal to the number of processors on the front end > native servers, or keepalive has to be disabled (resulting in > performance degradation); the benefit for AJP seems to actually be > greater than for HTTP (special thanks to Mladen who explained to me the > situation in detail) > - efficient static file serving (not done yet) > - (likely) better performance and reliability on free JVMs > - probably slightly better performance (over NIO, Mladen measured 10%, > while I measured 0%; as classic IO is a bit slower generally, I expect a > small improvement); unfortunately, maximum throughput suffers (maximum > throughput is measured by ab with keeplive enabled on localhost), as we > cannot just block on the read until the next request comes; the > benchmarks I use usually suck anyway ;) > - SSL support through OpenSSL (not done right now) > - access to certain useful native functions (detailed system status > information, random data generation, etc) > > This would effectively make Tomcat more appealing to the lower end > servers and, hopefully, web hosting companies (due to lower resource > usage). Large sites would likely also benefit a little from the AJP > improvements. > > The implementation would be an alternate endpoint implementation, > replacing PoolTcpEndpoint. Alternate HTTP/1.1 processor and socket > channel (for AJP) will be provided. Development required is actually > fairly small (significant testing will be required, however). I didn't > do the updated socket channel yet, but after 3 days of hacking, HTTP > works (and the AJP stuff should be much faster to do). > > Now the tricky points: > - is it appropriate for 5.5 ? I'd say yes, as it will be a separate > independent implementation > - will require APR, and a small JNI friendly wrapper library > tentatively named libtcnative by Mladen (Windows binaries - and likely > others - will be provided); portability should be good > - we'll need to improve performance (and especially fix the kludge that > is currently used to decide if a socket should be put inside a poller) > > Comments ? > > Rémy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
