2

I have a mostly static site running on Ruby on Rails that is using the Varnish reverse proxy cache to save on hits to the Rails backend.

The problem is that a user can login to the site and when they do we use ESI (edge side includes) to show user specific parts of the page.

Using ESI means that we have to disable Gzip compression on the Rails backend (using Nginx+passenger) or varnish cannot parse the data returned from the backend in order to run ESI processing.

My question is, do the benefits of using a reverse proxy cache outweigh the benefits of gzipping all your content? Or should I try to get rid of ESI complete and have the best of both worlds?

davidsmalley
  • 457
  • 1
  • 6
  • 14

2 Answers2

4

You could get the best of both worlds if you arrange things like so:

User -> nginx -> Varnish -> Rails

Turn gzip compression on from nginx to user. That's the slowest segment and also the most costly. I am assuming that your nginx, Varnish and Rails instances are local to each other. Your local bandwidth should be more than sufficient. Besides it does not make too much sense to gzip only to decompress to assemble the ESI.

Jauder Ho
  • 5,507
  • 2
  • 19
  • 17
  • Because I'm using nginx+passenger this would have to look like: User -> nginx -> Varnish -> nginx -> Rails However, maybe that's not such a big issue to have another nginx instance running. – davidsmalley Jul 15 '09 at 11:23
  • Heh. I did not know it was possible to accept an answer without an upvote =) But to your comment, it's not a big deal as nginx is sufficiently lightweight that it just switches accordingly. Additionally, should you grow sufficiently, you could locate the second nginx on a different server, essentially acting as another layer of load balancing/proxying. So still a win. – Jauder Ho Jul 15 '09 at 23:56
  • I didn't have enough rep to up vote when I accepted the answer. I do now though. – davidsmalley Jul 17 '09 at 10:04
-3

If bandwidth is not a problem, and load times are acceptable without gzip, you should definitely leave gzip turned off.

Gzipping takes a lot of CPU resources. So, if you're more concerned about CPU than bandwidth, if the site loads fast enough, and if ESI is a great help for you, then definitely the reverse proxy cache system has more benefits than gzipping http responses.

In others situations, where bandwidth is critical, gzip can be more important, but it doesn't seem to be the case here.

Finally, gzipping can be done by some reverse proxies. This is a great possibility, because reverse proxies generally doesn't use much CPU (if they are on a separate server). This saves the backend a lot of CPU cycles, and saves bandwidth as well, but at the moment, and if I remember correctly, Varnish doesn't support gzipping.

FWH
  • 288
  • 1
  • 2
  • Yep - no native gzip support for varnish at the moment http://varnish.projects.linpro.no/wiki/FAQ/Compression – davidsmalley Jul 15 '09 at 11:22
  • I'm not sure where you are getting your numbers from but you might want to check out Paul Buchheit's recent posting about this. gzip really is not that costly compared to the bandwidth savings. http://paulbuchheit.blogspot.com/2009/04/make-your-site-faster-and-cheaper-to.html – Jauder Ho Jul 15 '09 at 11:24
  • Also with the static module compiled in, you can pre-compress the file and nginx will just shoot that file over the wire. – Jauder Ho Jul 15 '09 at 11:28