
Varnish Cache 6.0.0 - conductor
https://varnish-cache.org/releases/rel6.0.0.html
======
kev009
I work in the CDN industry and am also heavily involved in the FreeBSD
community. I find Varnish to be kind of a tragic curiosity in that is has nice
fit and finish but is pretty unsuitable for high scale workloads due to the
influence of its creator phk@. Ironically on the OS he should know like the
back of his hand, sched_ule(4) has fairly expensive depth searches to ensure
process fairness. Doing a thread per connection is about the worst conceivable
design for web acceleration. It is probably ok for low connection count high
bandwidth (like chunked video streaming), but you're still going to be
dropping performance on the floor vs other I/O models as you get into the
1000s of connections, and as Netflix has publicly shown that is modern reality
on FreeBSD with 100gbit networking.

My understanding is that fastly has rewritten the I/O model upon more industry
standard event polling worker threads. They also reworked a lot of the memory
model using
[https://github.com/fastly/uslab](https://github.com/fastly/uslab). None of
that I/O work is upstream and it's unlikely it ever will be because of the
phk@ influence and perhaps fastly sees it as IP. So be prepared to do some
deep systems work if you need high scalability out of Varnish.

Apache Traffic Server is the most ready "out of the box" caching software for
rolling a CDN that I've seen. If you're going to do custom development, nginx
is a good I/O and HTTP model but be prepared to roll a complete cache storage
model from scratch.

~~~
orf
> They also reworked a lot of the memory model using
> [https://github.com/fastly/uslab](https://github.com/fastly/uslab).

Can anyone explain what being 'ABA-safe' means? I've not come across this
before and Google is not being helpful.

~~~
clan
I had a little more luck. I assume it is this:

[https://en.m.wikipedia.org/wiki/ABA_problem](https://en.m.wikipedia.org/wiki/ABA_problem)

------
phkamp
In case any of you have questions about V6, I'll keep an eye on this thread to
answer them today.

Contrary to the trollish claims below, Varnish works quite nicely, and is
involved in around one fifth of all HTTP traffic globally.

~~~
pestaa
kev009 doesn't seem to argue that Varnish "doesn't work quite nicely", but
that it has deep architectural limitations exposed in environments requiring
high scaling.

WordPress is involved in even more than 20% of all HTTP traffic globally, yet
it is the target of frequent criticism (whether rightfully or not is besides
the point). Popularity doesn't grant free pass on valid feedback.

~~~
kev009
Yes as I said Varnish has great fit and finish. If you have a small pool of
servers my comments will mean little to overarching business decisions.

To clarify my own part, this was in the back of my mind [http://varnish-
cache.org/docs/trunk/phk/notes.html](http://varnish-
cache.org/docs/trunk/phk/notes.html). It's written sanctimoniously and is
wrong. I care a lot about the profession of systems programming and hate to
see people misled. If calling bullshit is trolling I guess everyone is either
a bullshitter or a troll.

I contest most the points in that page. Varnish I/O model is ignorant of TLB
flushing, instruction cache, VM hints like madvise(2), and the overhead (and
downright difficult job) of an OS scheduler, as well as high performance
networking KPIs like load balancing SO_REUSEPORT or RSS. In a production web
cache there are very good reasons you might want to park some objects in
memory outside the vfs (the vfs is demand paged and also carries heavy
nontrivial locking). The stuff under the header "More caches" is correct, and
trivially dealt with using per worker (cpu) APIs, see counter(9) in the
FreeBSD kernel for a nice example.

By the text of the page, Varnish remains 2006 software. It's now 2018 and 48
hardware threads are common on servers, RAM is commonly measured in many
hundred GB, and multicore programming is beginning to mature with high quality
software, libraries, books, and tooling like Intel's VTune available.

If my points didn't have some validity, Fastly would not have done what they
did. That's all I have to say. I don't know nor care about phk (and find the
"smear me" comment hilariously paranoid), but a lot of the technical marketing
is bullshit and these problems could be fixed if he were willing to back down
and revisit the bold claims.

~~~
reza_n
This is another misinformed rant.

> Varnish I/O model is ignorant of TLB flushing, instruction cache, VM hints
> like madvise(2), and the overhead (and downright difficult job) of an OS
> scheduler.

TLB flushing is a hardware problem, not a software problem. Instruction cache?
Last I checked, the varnishd binary is about 2MB and uses very predictable
jumping and straight function calling. Im pretty sure your going to be getting
a 99% instruction cache hit rate. Madvise is used in Varnish's storage
engine's, and there seems to be little interest or knowledge about how Varnish
uses storage here.

> If my points didn't have some validity, Fastly would not have done what they
> did.

Can you expand on what Fastly did? They published a non locking memory
allocator? So the claim is that memory allocation is the bottleneck and
jemalloc is not suitable?

Sounds like someone might be stuck in performance hell and you are trying to
draw parallels to Varnish which simply don't exist!

~~~
kev009
You don't understand TLB. It is distinctly not a hardware problem. A TLB is a
content addressable memory and the mappings and flushing are done by..
software. You flush it every time you context switch, and pretty much fully
all the time with KPTI now that PCID's 4096 ASIDs can't safely save anything
other than the kernel and runnable process. My point about madvise protects
against PHKs post claiming memory pool objects will always be paging in and
out, which is false and again a memory pool is desirable for certain uses as
it guarantees maximum latency and avoids very heavy locking in the VFS for
high concurrency.

------
HugoDaniel
Cool, I have been using Varnish for a few years, mostly in front of wordpress
sites. Amazing product, almost no config and no worries :D It has made the
life of my users much better.

------
rcarmo
I’m curious. Since SSL is not supported (plenty of info about why in the
docs), what are people using besides HAProxy in front of Varnish?

~~~
phkamp
Pretty much whatever they prefer, and pretty much anything can work so take
your pick.

My personal preference is 'hitch' because I want as few lines of code involved
with the certificates as possible.

For important sites, I recommend running two different SSL implementations, so
that you are not dead in the water when a bad CVE in one of them comes around.

