Let’s talk about speed. Speed is important. Varnish is a synonym for speed. That far, that good. But am I really the only one who doesn’t get why it would be so important to be able to PURGE 4000 objects a second?
Really, who the fuck cares? Wouldn’t it show a bigger problem if I regularly end up with the need of purging oh so many objects and my patience only lasts 1 goddamn second? The reason I got objects with a fat TTL in my cache is that these objects are supposed to be valid for at least that long. So if I already determined that, why would I suddenly need to purge them and why would it all have to be done within the next half-second?
My point is, if I got so many objects to purge – every. freaking. second. – so many in fact that suddenly it matters to be able to purge 4000 a second instead of only 700 a second, why wouldn’t I set the TTL lower and thus let them basically purge themselves? If you constantly got to purge objects I’d guess you should rethink how long you really want to cache them.
And to finally reveal my real agenda here: I strongly believe that professional users of Varnish (the ones who understand what RFC 2616 stands for and why it would be sensible to follow standards) would prefer real problems to be fixed instead of having the VAC purge faster than anybody, who knows what he is doing, deems necessary.
Yeah, you got that right. I’m complaining about a WONT-FIX bug-report from 4 years ago. Don’t you believe for a second that people forgot about it or accepted the decision. I welcome every bug-report holding you responsible for your decision. I just hope the accepted solution won’t be a cheap paragraph in the documentation stating: “We know what the RFC says and what the average Joe expects. We just don’t care.”
Sensible defaults matter.
Update
Here’s for the lazy ones, the hasty readers: Of course I’m not talking about the speed of Varnish doing the PURGE. Why on earth would there be a limit of 4000 purges a second in Varnish? After all it is not written in Java. It will purge as fast as you can throw PURGE requests at it. No, this post is all about the VAC. Using enterprisy crap and frameworks blown out of proportion to the point that you start wondering where did all this shit go wrong in the first place, and then, after kicking that stuff to the curb and writing it yourself, triumphantly claiming to have the fastest thingamyjig there is – that is no fucking achievement, it’s a late and very sad realization.
So there’s that.
Some rant. There is quite a lot to comment on here.
Sometimes you need to purge a lot of data. If you have a lot of data and it updates you need to purge or risk serving invalid data. There is no way around it. In this case the frequency was rather high (up to 4K/sec) with multiple datacenters across the globe making it non-trivial problem.
We took two approaches. One was the traditional Java way, using a existing framework and one writing everything from scratch in pure Java (that is what you get when you put C programmers to programming Java). The pure Java implementation peaked out at 30 or 40 K purges per second (we ran out of client capacity), about an order of magnitude more then the frameworky way of doing it. An interesting point in itself.
Wrt to not being a traditional HTTP proxy in the RFC2616 sense, that is something we’ve been dealing with from the start. The IETF only has some briefs mentions of HTTP Surrogate Proxies without really defining their behaviour properly and so we were left with defining our own behaviour.
This is, as you point out, a documentation problem. I’d be very happy if you could outline in what part of the existing documentation I should highlight this fact.
Regarding
PURGE: I still feel that there is something fundamentally wrong if one constantly needs to purge that many objects. Like one didn’t think hard enough before implementing any kind of caching. If their approach to caching is to hit Google, do a sloppy copy/paste job and then complain that the tool they use to purge data can only do X objects a second — then yeah, the faster the better. It hides the fact that they suck at their job. Good for them, I guess.Regarding
RFC: A separate chapter about philosophy might be in order. But then again, if every user, who does more than install Varnish and then ask the mailing-list why it doesn’t cache, complains about the fact, why impose that philosophy in the first place? After all, you said it yourself. There is no hard rules for this situation. Why not create one which appeals to the majority (who know their shit) because it just makes sense? Varnish shouldn’t cater to the needs of dimwits who wouldn’t understandCache-Controlif you force-fed them with brains. Fucking IT is not easy when it’s done right. I’m tired of “professionals” thinking it’s enough to know how to install something so they can call themselves an expert senior architect IT consultant god-sent. They shouldn’t be the target audience. Their job shouldn’t be Varnish administration. Their job should be to ask “Do you want fries with that?”.But you know, as I’m known to be a very constructive person (haha), here’s my 2 cents to where in the documentation the philosophy of Varnish should be mentioned:
The first one makes it look like Varnish honors all of the possible values in the Cache-Control Header and the second one should be the one pointing out – again – that what you wrote is what you mean. It could be understood as though you were documenting the important parts while everything in the first chapter still applies (which it does not).
Thanks for the doc points. I’ll see what I can do to incorporate it.
I can’t say I have a strong opinion on the matter as you have so I probably won’t be pushing hard to get the change past PHK.
Re the purging: Believe me, these guys are cluefull. Do not assume that someone is stupid just because they have different needs than you do. If you have one million documents online and a lot of them are derived from the same source you will have a sudden need to invalidate a lot of them. And since you might be bound by some US federal regulation not to serve invalid data older than a certain time you need to purge it fast. That doesn’t mean you constantly purge thousands of objects per second. You just need to able to do so.
Cheers,
Per.
https://www.varnish-cache.org/lists/pipermail/varnish-commit/2013-February/009356.html
Are you ecstatic now?
And they said that bitchin’ and moaning doesn’t help. Choke on that politically correct people!