Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've serveral backends (one is nginx+passenger) to combine via ESI. Since I don't want to go without gzip/deflate and SSL varnish can't do the job out of the box. So I thought about the following setup:

http://img693.imageshack.us/img693/38/esinginx.png

What do you think? overkill?

share|improve this question
    
I can't make heads or tails of that diagram. –  cagenut Dec 18 '09 at 18:42
add comment

5 Answers

Do you need varnish at all?

1. nginx can cache results on disk or in memcached
2. nginx has SSI
3. nginx has fair load balancer or ey-balancer
4. Best practice says that HAProxy before nginx is good move.

Don't forget about KISS - more components your system has - less stable it becomes.

share|improve this answer
    
Moreover, Nginx SSI is much better and more featured than the Varnish ESI... –  Thomas Decaux Aug 14 '12 at 10:11
add comment

Based on the diagram, I'm not sure exactly what what you're trying to do (what is ESI?). However, there's a small, fast load-balancing front-end server called "pound" and it will handle the SSL layer for you. It could sit alongside Varnish on the front end on port 443 (I assume you have Varnish on port 80?) and pass the SSL traffic directly to nginx (SSL can't be cached anyway, so no point in going through Varnish). Normal, unencrypted traffic would go to Varnish as expected.

share|improve this answer
    
+1 for pointing, that SSL encrypted traffic could be cached properly, because it is encrypted using different keys per connection. Varnish should be placed between nginx frontend server and reverse proxy, where SSL is terminated. But this architecture is more complicated. –  sumar Dec 19 '09 at 1:11
    
Adding a forking proxy in front of Nginx would cut performance. Just configure Varnish to not answer requests on port 443 (it won't anyhow) and let Nginx handle SSL. –  deleted Apr 1 '10 at 19:25
add comment

While I haven't personally used it, Nginx does have an ESI plugin:

http://github.com/taf2/nginx-esi

share|improve this answer
add comment

If ESI is an absolute must I'd recommend the following set up

User -> Nginx (gzip+proxy+ssl termination) -> Varnish (ESI) -> Ngnix App Server.

That way you don't have to delegate your ssl, gzip requests to one back end server, and the ESI requests to another.

Have Varnish strip the Accept-Encoding headers from the incoming requests, that way your backends won't try to gzip (iff they're configured to do so), and Varnish can parse your backend response objects for ESI includes. Varnish will then present to your Nginx proxy fully formed content. That leaves the Nginx proxy to do compression and SSL delivery.

I've got a very similar setup running in production (without the SSL termination), and I've found it works quite gracefully.

share|improve this answer
    
Then your ESI pages won't be gzipped? –  Joris Sep 17 '10 at 6:16
    
Yup they do, because Nginx still receives the Accept-Encoding header, it takes the response from the Varnish server (be they ESI's, static, dynamic) and gzips it. –  flungabunga Oct 27 '10 at 0:53
add comment
Server       Requests per second
--------------------------------
G-WAN Web server       142,000 
Lighttpd Web server     60,000
Nginx Web server        57,000
Varnish Cache server    28,000

Save yourself the hurdle (and the bloat) of another intermediate layer. Just using a better server seems to be more efficient.

share|improve this answer
1  
That link is all about serving small static files, which is not really what the original post is about; caveat emptor, etc. –  nickgrim May 31 '11 at 10:59
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.