yum upgrades for production use, this is the repository for you.
Active subscription is required.
The Internet is full of useful bits of advice. If you’re working with servers or IT in general, you can’t go on with your work without searching for solutions.
But often times the advice is wrong.
Searching for perfect Varnish config? Stop
Let’s admit it. People have a hard time configuring Varnish for the first time. They search for ready Varnish VCL and end up with caching too many requests, or caching none at all.
At best, you’d be adding some unnecessary strain to your Varnish server by following wrong advice. Here is one shiny example:
Remove hash from URL
# Strip hash, server doesn't need it.
if (req.url ~ "\#") {
set req.url = regsub(req.url, "\#.*$", "");
}Not only server doesn’t need it. Server doesn’t see it!
The part of a URI after the hash (#) is called “fragment” and is by definition only available/processed on the client side. So why would you add the code above to your Varnish server VCL? – Exactly, for no reason at all!
Whatever is provided in the hash of URLs, will never reach your Varnish server or underlying backend. So adding that popular bit of VCL will add nothing but unnecessary processing logic and load to your server.
Now, you may think it’s fast anyway. But imagine you have high traffic website. Every bit of processing counts, since you want to process requests as fast possible.
Introducing unnecessary snippets of code to your VCL makes it also less readable.
So my advice #1: try to understand researched solutions before ever implementing them. And learn through that.
Happy searching!
