Do I need the Apache web server for better performance?

[Dave Smith <da...@nbnet.nb.ca>]

Hi,
Is there any performance benefit to having the Apache web server broker 
SOAP requests through the Tomcat servlet engine.  In the solution I'm 
implementing Apache will never be required to serve static content?
Is Tomcat robust enough to stand on it's own as the rpcrouter?  Are 
there other considerations I should look at that would benefit from an 
Apache/Tomcat solution rather than just Tomcat.

Thanks,
Dave

Re: Do I need the Apache web server for better performance?

[Dirk-Willem van Gulik <di...@covalent.net>]

On Sat, 24 Nov 2001, David Wall wrote:

> > there other considerations I should look at that would benefit from an
> > Apache/Tomcat solution rather than just Tomcat.
..
> Age old questions. Tomcat can do it all, as I understand it, especially TC
...
> 1) Everything is SSL in our site, and the OpenSSL implementation is faster
> than the JSSE.  Also, the SSL burden can be separated onto a second server.

And if you use one of the commercial Apache's (say from IBM or Covalent)
who rely on a commercial SSL stacks from for example RSA - then you get at
least another order of magnitude in SSL performance (and open the road to
hardware acc.  if need be). This assuming of course that you need 10's
of hits/second levels of performance :-)

Dw

Re: Do I need the Apache web server for better performance?

[Dirk-Willem van Gulik <di...@covalent.net>]

On Sat, 24 Nov 2001, David Wall wrote:

> > there other considerations I should look at that would benefit from an
> > Apache/Tomcat solution rather than just Tomcat.
..
> Age old questions. Tomcat can do it all, as I understand it, especially TC
...
> 1) Everything is SSL in our site, and the OpenSSL implementation is faster
> than the JSSE.  Also, the SSL burden can be separated onto a second server.

And if you use one of the commercial Apache's (say from IBM or Covalent)
who rely on a commercial SSL stacks from for example RSA - then you get at
least another order of magnitude in SSL performance (and open the road to
hardware acc.  if need be). This assuming of course that you need 10's
of hits/second levels of performance :-)

Dw

Re: Do I need the Apache web server for better performance?

[David Wall <dw...@Yozons.com>]

> Is there any performance benefit to having the Apache web server broker
> SOAP requests through the Tomcat servlet engine.  In the solution I'm
> implementing Apache will never be required to serve static content?
> Is Tomcat robust enough to stand on it's own as the rpcrouter?  Are
> there other considerations I should look at that would benefit from an
> Apache/Tomcat solution rather than just Tomcat.

Age old questions. Tomcat can do it all, as I understand it, especially TC
4.

We use Apache for the following reasons:

1) Everything is SSL in our site, and the OpenSSL implementation is faster
than the JSSE.  Also, the SSL burden can be separated onto a second server.

2) We do have limited static content, including W3C's P3P descriptions,
images, downloadable files, some static html (such as javadocs), and Apache
serves them more efficiently than does TC 3.2 which I'm still using.

3) We require that the web server run on port 80/443, which requires a root
startup under Linux.  Didn't want to run TC as root for security concerns
(though not because of a known exploit), and without doing so, TC can't
serve on ports below 1024.

4) Our security architecture required that the public web site server be
physically separate from the app server (TC), and Apache provides a nice
separation in which TC can run on a private network not routing on the
public internet, and we can place another firewall between the two limiting
traffic to just the mod_jk ports.

5) Apache has lots of modules that may be of use (CGI/perl, rewrite, proxy,
python, php...).

David

Re: Do I need the Apache web server for better performance?

[David Wall <dw...@Yozons.com>]

> Is there any performance benefit to having the Apache web server broker
> SOAP requests through the Tomcat servlet engine.  In the solution I'm
> implementing Apache will never be required to serve static content?
> Is Tomcat robust enough to stand on it's own as the rpcrouter?  Are
> there other considerations I should look at that would benefit from an
> Apache/Tomcat solution rather than just Tomcat.

Age old questions. Tomcat can do it all, as I understand it, especially TC
4.

We use Apache for the following reasons:

1) Everything is SSL in our site, and the OpenSSL implementation is faster
than the JSSE.  Also, the SSL burden can be separated onto a second server.

2) We do have limited static content, including W3C's P3P descriptions,
images, downloadable files, some static html (such as javadocs), and Apache
serves them more efficiently than does TC 3.2 which I'm still using.

3) We require that the web server run on port 80/443, which requires a root
startup under Linux.  Didn't want to run TC as root for security concerns
(though not because of a known exploit), and without doing so, TC can't
serve on ports below 1024.

4) Our security architecture required that the public web site server be
physically separate from the app server (TC), and Apache provides a nice
separation in which TC can run on a private network not routing on the
public internet, and we can place another firewall between the two limiting
traffic to just the mod_jk ports.

5) Apache has lots of modules that may be of use (CGI/perl, rewrite, proxy,
python, php...).

David

Re: Do I need the Apache web server for better performance?

[Dirk-Willem van Gulik <di...@covalent.net>]

On Sat, 24 Nov 2001, Dave Smith wrote:

> Is there any performance benefit to having the Apache web server broker
> SOAP requests through the Tomcat servlet engine.  In the solution I'm
> implementing Apache will never be required to serve static content?
> Is Tomcat robust enough to stand on it's own as the rpcrouter?  Are
> there other considerations I should look at that would benefit from an
> Apache/Tomcat solution rather than just Tomcat.

One big consideration is stack footprint. Typically most of the protocol
handling stack stays alive until well after the last byte has been
returned to the client (and logging has been done; etc). If you have a lot
of clients on relatively slow links - are sending quite some volume or are
quite detached - then it does make sense to let the much thinner apache
stack handle the boring stuff - so that the VM and the more volumenous
java stack can GC and do something more useful in the meantime.

I.e. you reduce the amounth of resources tied up during the whole request
by using a thinner server for the simple protocol handling.

Apart from that there are obvious scaling, robustness and security
advantages of using somethiing as batlte proven as apache as your front
line. When using SSL this gets even more extreme.

On the down side; the penalty is a few millisecond of latency and an extra
point of failure in your architecure.

I usually find that security, footprint and architecural flexibility win's
offset that in most but local LAN cases.

Dw

Re: Do I need the Apache web server for better performance?

[Dirk-Willem van Gulik <di...@covalent.net>]

On Sat, 24 Nov 2001, Dave Smith wrote:

> Is there any performance benefit to having the Apache web server broker
> SOAP requests through the Tomcat servlet engine.  In the solution I'm
> implementing Apache will never be required to serve static content?
> Is Tomcat robust enough to stand on it's own as the rpcrouter?  Are
> there other considerations I should look at that would benefit from an
> Apache/Tomcat solution rather than just Tomcat.

One big consideration is stack footprint. Typically most of the protocol
handling stack stays alive until well after the last byte has been
returned to the client (and logging has been done; etc). If you have a lot
of clients on relatively slow links - are sending quite some volume or are
quite detached - then it does make sense to let the much thinner apache
stack handle the boring stuff - so that the VM and the more volumenous
java stack can GC and do something more useful in the meantime.

I.e. you reduce the amounth of resources tied up during the whole request
by using a thinner server for the simple protocol handling.

Apart from that there are obvious scaling, robustness and security
advantages of using somethiing as batlte proven as apache as your front
line. When using SSL this gets even more extreme.

On the down side; the penalty is a few millisecond of latency and an extra
point of failure in your architecure.

I usually find that security, footprint and architecural flexibility win's
offset that in most but local LAN cases.

Dw