3 ms·
The big issue here is the application type. This only works well for a very particular type of application. That is, a highly dynamic site that is NOT dependent
by todsul 15y ago
The big issue here is the application type. This only works well for a very particular type of application. That is, a highly dynamic site that is NOT dependent on user logins.
1) If the site is only moderately dynamic, you can just use plain Nginx and set fastcgi_cache to a few minutes or hours. Much less load on the server. I like to keep things simple, I wouldn't even bother with Apache. Porting rewrites to Nginx is super simple.
2) If the site is customised on a per-user basis, 'microcaching' will break the site and have disastrous consequences. Every user will see the system customised for whichever user primed the cache.
My primary website is user based. That means this 'microcaching' concept wont work at all. It would be catastrophic.
That's where Varnish comes in with ESI. I really wish I didn't have to use Varnish. It's slower than Nginx, it adds another layer of complexity, and in testing, it seems slightly flaky. But what Varnish+ESI allows is caching of parts of my page that aren't user specific. I.e. header, footer, etc.
If you want to see my test results of Nginx vs Varnish, see http://todsul.com/nginx-varnish http://todsul.com/nginx-varnish
- chlee 15y agoI thought about incorporating Varnish into my side-project as well. However, Varnish seems to be a [potential] hassle when you account for VCL, ESI, and etc. It also adds an extra layer or indirection and complexity as you've mentioned. With regards to caching user specific parts of your page, have you considered template caching [1, 2]? This way you can apply different caching policies to different parts of your pages w/o using varnish and ESI. With that said, why would one choose Varnish + ESI (or reverse proxy in other words) over template caching + memcached/redis/riak? Can someone explain the pro's and con's of both approaches? [1] http://www.makotemplates.org/docs/caching.html http://www.makotemplates.org/docs/caching.html [2] http://jinja.pocoo.org/docs/extensions/ http://jinja.pocoo.org/docs/extensions/
- slyall 15y ago1. A reverse proxy will usually be faster since it doesn't have to execute an "code" (even a cut-down framework). 2. Some sites will be "read-only" and your really can serve everyone with exactly the same content. 3. Legacy codebase/programmers may not be able to use more scalable techniques so a reverse proxy is the best solution.
- todsul 15y agoYes, we previously used template caching because it was built into Symfony1 (an MVC PHP framework). Symfony2 now leaves caching to the HTTP Standard, plus integrates Akamai's ESI. Symfony specifically recommends Varnish for live projects. Memcache certainly has its place, but for me, Varnish is a plug-n-play solution that doesn't require code changes. Even with ESI, if you've already set HTTP Cache, you just need to set s-maxage per component. That's it. Then of course there's all the Varnish load balancing features that I haven't used. If my site didn't use logins, I'd definitely just go for Nginx + fastcgi_cache. People argue that Apache can do the same with the right tuning. But there's something to be said for a 5 minute VPS build by a complete novice that can serve 20,000 requests per second using about 10 lines of config code. I think this all becomes much more complicated for seriously large websites. That's where memcache/redis et al. join the party, potentially with Varnish.
- megaman821 15y agoIn my own use and benchmarks I have seen seen Varnish is faster than Nginx for full-page caching. Varnish with ESI will be slower of course. I think ESI is better for Facebook levels of personalization for light personalization ('Welcome, Bob!') using a cookies/javascript is better since it allows you to use full page caching again.
- klaruz 15y agoI agree, something seems wrong with that test. Varnish performance should not top out with the exact same performance no matter the concurrency. Here's an older article that shows with some very basic changes you can get 27k/s on an old single core machine: http://kristianlyng.wordpress.com/2009/10/19/high-end-varnish-tuning/ http://kristianlyng.wordpress.com/2009/10/19/high-end-varnis...
- todsul 15y agoIt's a totally different architecture. It's adding another layer. Why isn't it conceivable that adding this overhead would reduce speed? Remember, I'm not comparing a Varnish cache to an un-cached site. I'm comparing cache vs cache. Nginx serves static files very quickly. And cached files, in this case, are static. Also, these are single-server tests. Everything changes when you start talking about very large websites.
- todsul 15y agoHow can that be? If Nginx serves static files much faster, and full page caching is just a static file, how can Varnish be faster?