Up to this point, you’ve learned about best practices for implementing Varnish under ideal circumstances. But the real world is often less than ideal, and you need to know what to do when things don’t go according to plan.
This chapter will strike a balance between optimizing your application and just writing VCL to cope with the limitations of your application.
I remember when I started out with Varnish, I thought I had it all figured out. I read the manual, copy-and-pasted some VCL, and added a layer of Varnish to a client’s website. All of this was an attempt to protect my client’s website from the impact of a huge marketing campaign.
But it didn’t go as planned. I was caching too aggressively and even cached the cookies. This resulted in a cached version of the shopping cart and login page. Safe to say that the client wasn’t happy.
There were other instances where the hit rate was spectacularly low and that was because I was unaware of the built-in VCL. I was just writing VCL in
vcl_recv without exiting the subroutine with return statements like
pass. Varnish just went about its business and continued using default behavior that discarded my changes.
I see clients who write their own VCL make similar mistakes. Long story short: there are a bunch of common mistakes that people make, and here’s how to avoid the most common pitfalls.
Many people forget that Varnish creates a hit-for-pass ...