Hmm. I would think that the reason to use APR with Tomcat would be to
leverage Apache's SSL libraries. I'm not even sure if there's a big
performance benefit of that as opposed to alternative solutions such
as offloading SSL to a load-balancer. But you might benefit from
re-using Apache's SSL config.

I wouldn't really any benefit of embedding non-SSL traffic into Tomcat
via APR. I would still rather see Apache in front of your app server
because that gives you tangeible benefits that embedded APR doesn't:

1 - You can add/remove app servers without having to take website down
(though load-balancers can do this as well)

2 - You get extra security in particular for your database layer.

3 - You can take app servers down for upgrades/patches, etc and use
Apache to put up a down notice message.

Just some quick thoughts.

Mark

On 11/29/05, Patrick Casey <[EMAIL PROTECTED]> wrote:
>
>
>             Has anybody seen any actual performance numbers comparing Tomcat
> 5.5.x/JNI/APR with just plain Tomcat 5.5.x? Having built the shared
> libraries and installed them into my JRE, about all I can say is that using
> the APR makes configuration harder. The Tomcat doc makes noises to the
> effect that it "should" be faster in "some circumstances", but I can't find
> any actual benchmarks anywhere to confirm or deny up that particular
> statement. At the moment, my inclination is to just stick with straight java
> Tomcat on the grounds that it's one less moving part, but I'd like to get a
> feel for how much of a performance hit I'd actually be taking if I did so.
>
>
>
>             Does anybody know of any testing to that effect?
>
>
>
>             --- Pat
>
>
>
>             PS In case you haven't looked into this yet, recent versions of
> tomcat let you use JNI to natively invoke the (c language) apache portable
> runtime library on your server. So instead of having Apache fronting tomcat,
> you have tomcat calling through into the Apache Library. In theory this is
> easier to configure than apache->tomcat, but still faster than just plain
> tomcat. In practice, well, that's what I'm asking about.
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to