Why bother with APR?

[dmlloyd]

I've been having an email discussion with various parties about NIO versus APR. I'm thinking specifically in terms of Remoting, but I think that the discussion can be more generally applied.

What I want to know is, why we should bother (with a modern JVM) to use APR when NIO is standard and built in. Specifically, I have not found any published benchmarks about the subject, except for that published by Jean-Francois Arcand here:
http://weblogs.java.net/blog/jfarcand/archive/2006/03/can_a_grizzly_r.html

His findings seem to be that NIO performs as well as APR in Coyote, if not better. Are there any counter-benchmarks out there? Google didn't seem to turn up anything relevant. And, how big a margin is needed before it becomes worth it to use APR?

Personally I feel it would be far more productive, not to mention better for the community, to put our efforts towards working with the EG to improve NIO, if it is deficient in some way.

[mladen.turk]

The major usage of APR is to provide a high concurrency for Servlet like
engines changing the connection model from thread/connection to
thread/request beyond many others like OS sendfile support etc.

Comparing NIO to that model gives you few times performance
decrease over the APR.
Last time I compared Glassfish with Tomcat+APR it was 10 times (!) slower.

His other document
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-2992&yr=2007&track=5
says on slide 20 that Tomcat is still 10% faster then Grizzly (even without APR)

Nevertheless, benchmarks are like assholes. Everyone has one.

Regards,
Mladen

[rmaucher]

Actually, I think NIO is pointless. First, the API is more complex and not GC friendly, but more importantly, APR is already in production pretty much everywhere inside httpd.

OTOH, NIO is implemented as a bunch of native code inside the JVM, so it results in having more native code, and it's also more difficult to maintain (if you run into an NIO bug, there's no way to fix it except to update the whole JVM).

[mladen.turk]

Also speaking about performance:
http://labs.jboss.com/file-access/default/members/jbossweb/freezone/index.html

There are lots of other nice looking images if you are interested :)
I didn't publish them, just because I don't think the speed itself is that important.

I agree that if some concepts from APR backported to NIO would be very valuable. Especially the fast non-blocking/blocking transition.

[dmlloyd]

Actually, I think NIO is pointless.

I didn't ask, "Who here thinks NIO is pointless". I asked if there were any good benchmarks comparing NIO to APR in terms of performance.

I've also heard things like "APR is more flexible", but I haven't seen any information to back that up either.

[timfox]

Actually, I think NIO is pointless.

I didn't ask, "Who here thinks NIO is pointless". I asked if there were any good benchmarks comparing NIO to APR in terms of performance.

I've also heard things like "APR is more flexible", but I haven't seen any information to back that up either.

I believe the RHM team compared NIO (using Apache MINA) to Apache APR and also to asynchronous IO using direct Linux OS calls (i.e. not going through the APR abstraction layer).

I believe the direct hooks gave the best performance, NIO was pretty good, and APR not so good due to the overhead of having to find a common API over all OSs.

Sorry for the vaguities, but this is what I remember them mentioning. Don't know if their findings were correct or not.

BTW we (JBM) definitely need NIO for handling large number of connections. APR is a "nice to have" if it gives radically better performance than NIO, but I'm not particularly bothered about it.

[trustin]

"timfox" wrote:
I believe the RHM team compared NIO (using Apache MINA) to Apache APR and also to asynchronous IO using direct Linux OS calls (i.e. not going through the APR abstraction layer).

I believe the direct hooks gave the best performance, NIO was pretty good, and APR not so good due to the overhead of having to find a common API over all OSs.

Sorry for the vaguities, but this is what I remember them mentioning. Don't know if their findings were correct or not.

BTW we (JBM) definitely need NIO for handling large number of connections. APR is a "nice to have" if it gives radically better performance than NIO, but I'm not particularly bothered about it.

Is there any written report related with their findings?

I am with Tim in that APR is a nice-to-have. Some platform's NIO performance might not be better than APR and vice versa, so it would be nice if users can choose what the best is for their running platform.