Tomcat efficiency (was: RE: Optimal Settings to use Tomcat as a HTTP File Server)

[Jeff Sturm <je...@eprize.com>]

> -----Original Message-----
> From: Bill Miller [mailto:millebi.subscriptions@gmail.com]
> Sent: Monday, June 13, 2011 3:58 PM
> 
> >> Enlighten me: what is "the" reason that this is common practice?
...
> -Static image serving (much more economical because the HTTP server is much lighter
> "weight" than a JVM/App server) -etc...

I've heard this claim before, but I'm not so sure I believe it.  Apache httpd is a web server implemented in C that runs directly on the OS.  Apache Tomcat is a web server written in Java that runs on a JVM.  I'd hope both are written near-optimally for their respective environments, and there's no good reason Java needs to be slow.

I just tried a trivial benchmark of a static file (187 bytes) that yielded 3,223 req/sec from httpd, and 3,172 req/sec from Tomcat.  That's a difference under 2%.  A 2% performance difference isn't compelling enough to me to make an architectural decision one way or the other.  I haven't benchmarked larger files, but I can imagine that APR's sendfile support would give Tomcat an assist there.

On the other hand, there are other good reasons to use Java as a web server in favor of httpd.   Security, for one--I shouldn't need to worry about e.g. stack buffer overflow exploits when running a Java server.

My hope is that Tomcat and its ilk will slowly replace older web server technology for static and dynamic content alike.  That's not just for simplicity's sake, but that I also see the difference between "static" and "dynamic" requests starting to evaporate.  We serve a lot of cacheable requests from our application, all idempotent requests, and they are not normally backed by file system content.  They could just as well be a row in a database or search engine results.  The distinction of "static" content (i.e. content served by files on a file system) isn't useful to me because it's not very different than content served from other sources.  But, unlike Apache httpd, Tomcat is built on a technology that is very easy to extend for e.g. database access.

The architectural shift away from file content seems to be accelerated by adoption of distributed and (especially) cloud computing, in which a central read/write file system is not always convenient or available.  Distributed file systems exist but have not proven to be as effective as relational databases or any of the No-SQL technologies such as Hadoop.  Hence the traditional "static" vs. "dynamic" distinction is most likely becoming obsolete.

-Jeff

Re: Tomcat efficiency (was: RE: Optimal Settings to use Tomcat as a HTTP File Server)

[Peter Crowther <pe...@melandra.com>]

On 13 June 2011 21:41, Jeff Sturm <je...@eprize.com> wrote:

> > From: Bill Miller [mailto:millebi.subscriptions@gmail.com]
> > -Static image serving (much more economical because the HTTP server is
> much lighter
> > "weight" than a JVM/App server) -etc...
>
> [...]

I just tried a trivial benchmark of a static file (187 bytes) that yielded
> 3,223 req/sec from httpd, and 3,172 req/sec from Tomcat.  That's a
> difference under 2%.  A 2% performance difference isn't compelling enough to
> me to make an architectural decision one way or the other.  I haven't
> benchmarked larger files, but I can imagine that APR's sendfile support
> would give Tomcat an assist there.
>
> http://tomcat.apache.org/articles/benchmark_summary.pdf

I seem to recall some more recent benchmarks as well?  The summary I've seen
is "you'll run out of network bandwidth long before you run out of the
capacity to serve static files in any modern system, whether you're using
httpd or Tomcat".

- Peter

Re: Tomcat efficiency (was: RE: Optimal Settings to use Tomcat as a HTTP File Server)

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff,

On 6/13/2011 4:41 PM, Jeff Sturm wrote:
>> -----Original Message-----
>> From: Bill Miller [mailto:millebi.subscriptions@gmail.com]
>> Sent: Monday, June 13, 2011 3:58 PM
>>
>>>> Enlighten me: what is "the" reason that this is common practice?
> ...
>> -Static image serving (much more economical because the HTTP server is much lighter
>> "weight" than a JVM/App server) -etc...
> 
> I've heard this claim before, but I'm not so sure I believe it.
>
> I just tried a trivial benchmark of a static file

I have better benchmarks, I think:

http://people.apache.org/~schultz/ApacheCon%20NA%202010/

> On the other hand, there are other good reasons to use Java as a web
> server in favor of httpd.   Security, for one

+1

One could argue (and others have, in another thread) that the app server
(with it's usually more-privileged role among servers) is inappropriate
to be Internet-facing, and I agree. Were Tomcat to include an HTTP
proxying capability (which it doesn't) that performed well (which it
could), I might even recommend replacing Apache httpd with Tomcat for
static file-serving for just security reasons.

Apache httpd is pretty secure, though, in it's default configuration
when kept up-to-date. ;)

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk32jNYACgkQ9CaO5/Lv0PAHSgCfdWzzez5DQ3CknIuJnhot30mI
8YwAn3aRepmkLQ071mosobQj0CGfiTV6
=opVW
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org