To play devil's advocate for a moment, however, would use of Java NIO potentially make more sense for Tomcat, i.e. to take a step forward in terms of performance, etc, without requiring native code? [I'm not saying NIO covers all the bases APR would or is as fast. Rather wondering whether performance efforts should not remain in the pure Java space until that is truly exhausted.]
-- Jess Holle
Remy Maucherat 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]
