Reverse proxy : lighttpd vs. nginx fight!

Hi guys. I am currently using lighttpd 1.4.xx to manage our rails
processes using FastCGI. I love lighttpd - it’s fast, stable, and easy
to configure. Our app fits nicely within a single machine at the
moment.

Our traffic is increasing rapidly and I’m starting to contemplate the
jump to multiple machines. I will be using a reverse proxy in front of
my lighttpd boxes. I would love to use lighttpd as the reverse proxy,
but I’m discouraged by some of the rumors: http://
mongrel.rubyforge.org/docs/lighttpd.html

I started playing with nginx and I’m impressed so far. I miss
lighttpd’s gzip caching, but overall it seems quite capable.

Any opinions on lighttpd vs nginx reverse proxies? War stories? Is
anyone running lighttpd 1.5.0 prerelease in production?

Thanks,

Adam

Hi Tom. Thanks for the reply. Comments follow:

Tom M. wrote:

I started playing with nginx and I’m impressed so far. I miss
lighttpd’s gzip caching, but overall it seems quite capable.

nginx has gzip compression.

Lighttpd will take your static files, compress with gzip as required,
and cache the results to disk. Nginx supports on the fly gzip
compression but as far as I can tell it doesn’t cache the results. I’m
not interested in compressing all response bodies on the fly with nginx
because that seems like it’ll eat large amounts of CPU.

I definitely want compression because it improves the user experience,
so I may end up using lighty’s compression behind my reverse proxy.

When I first came on the Rails scene I too was impressed with Lighty.

It’s light, fast and simple.

But it had issues, including poor proxying and memory leaks.

nginx is lighter, faster, and has fewer memory leaks.

Lighttpd is working great for me as a FastCGI host, but I’m nervous
about using it as a reverse proxy. Your reply counts as another big
thumbs down for lighty’s proxying. Still, I probably won’t abandon
lighty for my FastCGI hosting unless I start to encounter problems.

Adam

On 2/2/07, amd [email protected] wrote:

Hi guys. I am currently using lighttpd 1.4.xx to manage our rails
processes using FastCGI. I love lighttpd - it’s fast, stable, and easy
to configure. Our app fits nicely within a single machine at the
moment.

Our traffic is increasing rapidly and I’m starting to contemplate the
jump to multiple machines. I will be using a reverse proxy in front of
my lighttpd boxes. I would love to use lighttpd as the reverse proxy,
but I’m discouraged by some of the rumors: http://
mongrel.rubyforge.org/docs/lighttpd.html

Lighty can proxy to multiple machines via FCGI, but you’ll be better off
with nginx+mongrel IMHO.

I started playing with nginx and I’m impressed so far. I miss
lighttpd’s gzip caching, but overall it seems quite capable.

nginx has gzip compression.

Any opinions on lighttpd vs nginx reverse proxies? War stories? Is
anyone running lighttpd 1.5.0 prerelease in production?

When I first came on the Rails scene I too was impressed with Lighty.

It’s light, fast and simple.

But it had issues, including poor proxying and memory leaks.

nginx is lighter, faster, and has fewer memory leaks.


– Tom M., CTO
– Engine Y.

On 2/2/07, Adam D. [email protected] wrote:

not interested in compressing all response bodies on the fly with nginx
because that seems like it’ll eat large amounts of CPU.

Isn’t that a bit of a pre-optimization?

Don’t guess, benchmark!

You might find nginx is faster, and uses less CPU, or you might find
the opposite.

In any case, how many static files do you serve? There’s no need to
compress already compresses resources, such as images.

We’ve been using nginx + gzip compression and find the CPU usage to be
minimal. Today’s processors are quite fast for those sorts of
operations.


– Tom M., CTO
– Engine Y.

On Feb 4, 1:19 pm, Adam D. [email protected] wrote:

If I have 100,000 visitors to my site I would prefer to compress the
stylesheet once instead of 100,000 times.

What if compressing it 100,000 times only takes .5% CPU in that
time frame, and the site is faster, more responsive, and more stable
using nginx?


– Tom M., CTO
– Engine Y.

Tom M. wrote:

You might find nginx is faster, and uses less CPU, or you might find
the opposite.

In any case, how many static files do you serve? There’s no need to
compress already compresses resources, such as images.

We’ve been using nginx + gzip compression and find the CPU usage to be
minimal. Today’s processors are quite fast for those sorts of
operations.

If I have 100,000 visitors to my site I would prefer to compress the
stylesheet once instead of 100,000 times.

Still, I’m pleased to hear that nginx on-the-fly compression isn’t
impacting your CPU. I’ll turn it on and see what happens. Thanks for the
suggestions,

Adam