8 ms·

Varnish Cache 6.0.0

107 points by conductor 9y ago

kev009 9y ago
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 9y ago
  > 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.
  - kev009 9y ago
    https://en.wikipedia.org/wiki/ABA_problem https://en.wikipedia.org/wiki/ABA_problem
  - clan 9y ago
    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
- SEJeff 9y ago
  Thoughts on squid? I've seen it push 40G sustained no problem (4 10G interface setup with LACP) on Linux boxes.
  - kev009 9y ago
    Two of the earliest and biggest CDNs are based on squid. Very hacked up though. I have no direct experience with squid3.
    - SEJeff 9y ago
      Also, 100% of the internal CDN stuff for ticketmaster.com was squid. I know because I was on the team that configured them in ~2007.
  - petre 9y ago
    I've tried to configure squid as a load balancer, struggled, found out about varnish, gave it a try and never looked back. It has been working flawlessly from day one. We're caching geocoding and routing results from a web api, load round robin balancing between two backends.
- phkamp 9y ago
  I'm not going to reply to this, because you clearly have no first hand experience with Varnish and merely parrot what negative opinions you have been able to search out, in order to smear me, for reasons you don't disclose.
  - kev009 9y ago
    It's not about you in reality, just trying to save users some headaches. On the contrary you have no idea what I have tried and more importantly what rigorous comparisons my company has done to select the basis for our products. There are lots of choices, most of them have better trade offs. The ones I listed are also free software. It's no different than comparing/contrasting RDBMS.
    - phkamp 9y ago
      Yeah, right. Not at all a troll.
      - abritinthebay 9y ago
        You’re not helping. He brought up reasonable sounding criticisms and you responded with nothing but derisive insults. I respect your work but you’re making yourself look bad here. You appear to think he’s way off the mark technically so it should be easy to address his points, no?
        jasonwatkinspdx 9y ago
        Don't expect much. I've been on email lists with PHK since the 90's. He's never shown any sign of interest in behavior other than what you see above.
        jeremiep 9y ago
        Reading this thread reminds me of what Alan Kay said a few years ago: - The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs. I've been doing web dev for over 15 years and this quote is pretty much how I would describe the web development scene.
- bufferoverflow 9y ago
  We had really bizzare problems with Varnish ~6 years ago even under mild load (hundreds or requests per second). Like it would randomly let all the requests through to our origin servers, bringing them down. We struggled for months, multiple devops/sysadmins looked into it, couldn't figure it out. But when it worked, it was fast.
  - phkamp 9y ago
    That sounds like the dreaded "Long TTL hit-for-pass object" issue. The situation happens when an object which should be cached gets hit with a request which causes 'pass' (typically because of headers tested in builtin.vcl) and then VCL (by accident) setting the long TTL for caching on the "hit-for-pass" object. It's an ugly corner case which we have struggled a lot with finding a solution for, which doesn't have worse side-effects than the problem we are trying to fix. I think it is mostly a solved problem from Varnish 5.
- icebraining 9y ago
  I don't get it, from what I can tell Varnish uses worker threads exactly as you're describing. What's the difference you're talking about? Regarding thousands of connections, people on the web report Varnish handling 10k connections[1] just fine after a few tweaks, and this was ten years ago. How can it suddenly be a problem? [1] https://varnish-cache.org/lists/pipermail/varnish-misc/2008-February/015804.html https://varnish-cache.org/lists/pipermail/varnish-misc/2008-...
  - the-dude 9y ago
    Funny you read it this way. I am seeing : after tuning the exact parameter OP is talking about, they are able to handle 10k at the extremes of 0% miss or 100% miss. What about 50%? Then they describe a setup where they have to reduce the active cores from 8 to 4 because otherwise it is extremely slow.
    - kev009 9y ago
      Correct see i.e. https://book.varnish-software.com/4.0/chapters/Tuning.html#threading-model https://book.varnish-software.com/4.0/chapters/Tuning.html#t... - a worker thread is used per request rather than industry standard polling loops for this kind of application. That doesn't mean you are setting up and tearing down a thread each time in varnish. Most modern data movers are based on something like epoll/kqueue/IOCP. A polling loop is more efficient because the kernel notifies a worker of only the lo/hi wat socket buffers and you only fill exactly when you need to in a tight loop. Using polling doesn't mean you give up multiple process or multiple thread workers, see nginx I/O model for a nice one [1]. With sendfile(2) and splice(2) you are only wiring up the activity to be done in your event loop, the data doesn't need to copyin/copyout from the kernel and back. [1] https://www.nginx.com/blog/socket-sharding-nginx-release-1-9-1/ https://www.nginx.com/blog/socket-sharding-nginx-release-1-9...
      - deleted 9y ago
        [deleted]
      - reza_n 9y ago
- reza_n 9y ago
  > Doing a thread per connection is about the worst conceivable design for web acceleration. A better statement here would be connections are serviced by a pool of workers. Event polling is used. A single worker can and does process tens of thousands of requests a second. Workers are used to get request parallelism across multiple cores. When a request blocks, that worker will work on another request. Varnish easily beats out pure event driven software in 99perc response times because of its worker pool designed. Very puzzling that you are claiming otherwise. > going to be dropping performance on the floor vs other I/O models as you get into the 1000s of connections I have done benchmarks with over 100,000 active connections a second, with a mix of blocked, slow, fast connections, cache hits, misses, and passes. Performance is great, ~100us response times, very low CPU utilization. > So be prepared to do some deep systems work if you need high scalability out of Varnish. Not at all. Once again, I did some benchmarks not too long ago and was able to get 100Gbit/sec using a stock Varnish + stock Linux. Response time was well under 1ms per request. Hitting high levels of scale and performance is an IO problem, not really a CPU problem. A lot of the criticism here is misinformed and focused on CPU scheduling. Not a single mention about any of the IO optimizations used in Varnish and other competing products.
  - kev009 9y ago
    You realize that's a fraction of what other like software can do on Linux right? I can't share our in house comparison, and they're on a modified FreeBSD vm and network stack so it's not applicable to the public anyway. Someone in the varnish org should be able to do a competitive analysis of Varnish, ATS, and Nginx in a couple days that would be enlightening and prudent use of time to guide your product development. You and phk both seem to think I have something to gain by seeing you fail; I don't and want you to succeed. Egos have to subside for progress to happen.
    - reza_n 9y ago
      > Someone in the varnish org should be able to do a competitive analysis of Varnish, ATS, and Nginx in a couple days that would be enlightening and prudent use of time to guide your product development. Really? I would say most of us are comfortable with how Nginx and ATS are engineered and how the kernel works. If anything, I think the concern is the fact that you are working for a publicly traded CDN yet you came to this thread armed with nothing more than a load of BS and FUD. I will say this connected a few dots in my mind and possibly added some color to what others think.
- ryan_jarv 9y ago
  Not familiar with varnish internals much but 1000 seems off, we where seeing steady performance at around 300krpm on a two node cluster iirc.
- ksec 9y ago
  Slightly off topic: Why might be the reason Apache Traffic Server usage hasnt caught on?
  - kev009 9y ago
    It has, LinkedIn's CDN, most cable companies. They list Akamai here but I'm not sure how much or what product line uses it http://trafficserver.apache.org/users.html http://trafficserver.apache.org/users.html
    - ksec 9y ago
      Missing Limelight? Or you guys use something else?
      - kev009 9y ago
        We have a legacy platform that has been rototilled over the past few years to work above 100g. That path was just reality to provide continuity of features and lessen the risk of overhaul over several years vs a brown/greenfield. Not advisable for newcomers. My original comment was not meant to be partial to any tech and targeted toward people starting new in house CDNs, I mentioned ATS as it gives you the best ready to scale platform right now and have no incentives for sharing that knowledge. If your core business is CDN the choice opens up to from scratch or bending something else. Cambridge has shown results that should go an order of magnitude beyond current software [1][2] and a low power FPGA design that I can't find at the moment that would both be a magnitude greater in efficiency than the software mentioned in this thread. In the mean time, using the conventional BSD stack we're closing in on 200gbps on single socket x86 hw and again hitting bus and memory bandwidth limits. [1] https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201408-sigcomm2014-specialization.pdf https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201408... [2] https://www.cl.cam.ac.uk/~rnw24/papers/201708-sigcomm-diskcryptnet.pdf https://www.cl.cam.ac.uk/~rnw24/papers/201708-sigcomm-diskcr...
- dormando 9y ago
  I worked on the fastly varnish fork. None of this is accurate. Definitely not "because of phk influence". Most of the details are obviously secret, but occasionally when we found something architecturally concerning I'd talk it over with phk in IRC and he would make his own fix. Fastly is a big complex distributed system loosely based on Varnish. There are several fantastic blog posts about Fastly's distributed architectural design, but nothing to my knowledge about anything else. Comparing single-machine scalability is completely inaccurate, mostly because you'll never know what fastly actually did or more importantly why they did it. In general the "big co's fork of X must be superior" is a trope I'm thoroughly tired of.
deleted 9y ago
[deleted]
phkamp 9y ago
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 9y ago
  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 9y ago
    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.
rcarmo 9y ago
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 9y ago
  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.
- amq 9y ago
  Nginx and Traefik.
- petre 9y ago
  Hitch in front of Varnish.
HugoDaniel 9y ago
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.

107 points by conductor 9y ago

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 9y ago
> 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.
- kev009 9y ago
  https://en.wikipedia.org/wiki/ABA_problem https://en.wikipedia.org/wiki/ABA_problem
- clan 9y ago
  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
SEJeff 9y ago
Thoughts on squid? I've seen it push 40G sustained no problem (4 10G interface setup with LACP) on Linux boxes.
- kev009 9y ago
  Two of the earliest and biggest CDNs are based on squid. Very hacked up though. I have no direct experience with squid3.
  - SEJeff 9y ago
    Also, 100% of the internal CDN stuff for ticketmaster.com was squid. I know because I was on the team that configured them in ~2007.
- petre 9y ago
  I've tried to configure squid as a load balancer, struggled, found out about varnish, gave it a try and never looked back. It has been working flawlessly from day one. We're caching geocoding and routing results from a web api, load round robin balancing between two backends.
phkamp 9y ago
I'm not going to reply to this, because you clearly have no first hand experience with Varnish and merely parrot what negative opinions you have been able to search out, in order to smear me, for reasons you don't disclose.
- kev009 9y ago
  It's not about you in reality, just trying to save users some headaches. On the contrary you have no idea what I have tried and more importantly what rigorous comparisons my company has done to select the basis for our products. There are lots of choices, most of them have better trade offs. The ones I listed are also free software. It's no different than comparing/contrasting RDBMS.
  - phkamp 9y ago
    Yeah, right. Not at all a troll.
    - abritinthebay 9y ago
      You’re not helping. He brought up reasonable sounding criticisms and you responded with nothing but derisive insults. I respect your work but you’re making yourself look bad here. You appear to think he’s way off the mark technically so it should be easy to address his points, no?
      - jasonwatkinspdx 9y ago
        Don't expect much. I've been on email lists with PHK since the 90's. He's never shown any sign of interest in behavior other than what you see above.
        jeremiep 9y ago
        Reading this thread reminds me of what Alan Kay said a few years ago: - The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs. I've been doing web dev for over 15 years and this quote is pretty much how I would describe the web development scene.
bufferoverflow 9y ago
We had really bizzare problems with Varnish ~6 years ago even under mild load (hundreds or requests per second). Like it would randomly let all the requests through to our origin servers, bringing them down. We struggled for months, multiple devops/sysadmins looked into it, couldn't figure it out. But when it worked, it was fast.
- phkamp 9y ago
  That sounds like the dreaded "Long TTL hit-for-pass object" issue. The situation happens when an object which should be cached gets hit with a request which causes 'pass' (typically because of headers tested in builtin.vcl) and then VCL (by accident) setting the long TTL for caching on the "hit-for-pass" object. It's an ugly corner case which we have struggled a lot with finding a solution for, which doesn't have worse side-effects than the problem we are trying to fix. I think it is mostly a solved problem from Varnish 5.
icebraining 9y ago
I don't get it, from what I can tell Varnish uses worker threads exactly as you're describing. What's the difference you're talking about? Regarding thousands of connections, people on the web report Varnish handling 10k connections[1] just fine after a few tweaks, and this was ten years ago. How can it suddenly be a problem? [1] https://varnish-cache.org/lists/pipermail/varnish-misc/2008-February/015804.html https://varnish-cache.org/lists/pipermail/varnish-misc/2008-...
- the-dude 9y ago
  Funny you read it this way. I am seeing : after tuning the exact parameter OP is talking about, they are able to handle 10k at the extremes of 0% miss or 100% miss. What about 50%? Then they describe a setup where they have to reduce the active cores from 8 to 4 because otherwise it is extremely slow.
  - kev009 9y ago
    Correct see i.e. https://book.varnish-software.com/4.0/chapters/Tuning.html#threading-model https://book.varnish-software.com/4.0/chapters/Tuning.html#t... - a worker thread is used per request rather than industry standard polling loops for this kind of application. That doesn't mean you are setting up and tearing down a thread each time in varnish. Most modern data movers are based on something like epoll/kqueue/IOCP. A polling loop is more efficient because the kernel notifies a worker of only the lo/hi wat socket buffers and you only fill exactly when you need to in a tight loop. Using polling doesn't mean you give up multiple process or multiple thread workers, see nginx I/O model for a nice one [1]. With sendfile(2) and splice(2) you are only wiring up the activity to be done in your event loop, the data doesn't need to copyin/copyout from the kernel and back. [1] https://www.nginx.com/blog/socket-sharding-nginx-release-1-9-1/ https://www.nginx.com/blog/socket-sharding-nginx-release-1-9...
    - deleted 9y ago
      [deleted]
    - reza_n 9y ago
reza_n 9y ago
> Doing a thread per connection is about the worst conceivable design for web acceleration. A better statement here would be connections are serviced by a pool of workers. Event polling is used. A single worker can and does process tens of thousands of requests a second. Workers are used to get request parallelism across multiple cores. When a request blocks, that worker will work on another request. Varnish easily beats out pure event driven software in 99perc response times because of its worker pool designed. Very puzzling that you are claiming otherwise. > going to be dropping performance on the floor vs other I/O models as you get into the 1000s of connections I have done benchmarks with over 100,000 active connections a second, with a mix of blocked, slow, fast connections, cache hits, misses, and passes. Performance is great, ~100us response times, very low CPU utilization. > So be prepared to do some deep systems work if you need high scalability out of Varnish. Not at all. Once again, I did some benchmarks not too long ago and was able to get 100Gbit/sec using a stock Varnish + stock Linux. Response time was well under 1ms per request. Hitting high levels of scale and performance is an IO problem, not really a CPU problem. A lot of the criticism here is misinformed and focused on CPU scheduling. Not a single mention about any of the IO optimizations used in Varnish and other competing products.
- kev009 9y ago
  You realize that's a fraction of what other like software can do on Linux right? I can't share our in house comparison, and they're on a modified FreeBSD vm and network stack so it's not applicable to the public anyway. Someone in the varnish org should be able to do a competitive analysis of Varnish, ATS, and Nginx in a couple days that would be enlightening and prudent use of time to guide your product development. You and phk both seem to think I have something to gain by seeing you fail; I don't and want you to succeed. Egos have to subside for progress to happen.
  - reza_n 9y ago
    > Someone in the varnish org should be able to do a competitive analysis of Varnish, ATS, and Nginx in a couple days that would be enlightening and prudent use of time to guide your product development. Really? I would say most of us are comfortable with how Nginx and ATS are engineered and how the kernel works. If anything, I think the concern is the fact that you are working for a publicly traded CDN yet you came to this thread armed with nothing more than a load of BS and FUD. I will say this connected a few dots in my mind and possibly added some color to what others think.
ryan_jarv 9y ago
Not familiar with varnish internals much but 1000 seems off, we where seeing steady performance at around 300krpm on a two node cluster iirc.
ksec 9y ago
Slightly off topic: Why might be the reason Apache Traffic Server usage hasnt caught on?
- kev009 9y ago
  It has, LinkedIn's CDN, most cable companies. They list Akamai here but I'm not sure how much or what product line uses it http://trafficserver.apache.org/users.html http://trafficserver.apache.org/users.html
  - ksec 9y ago
    Missing Limelight? Or you guys use something else?
    - kev009 9y ago
      We have a legacy platform that has been rototilled over the past few years to work above 100g. That path was just reality to provide continuity of features and lessen the risk of overhaul over several years vs a brown/greenfield. Not advisable for newcomers. My original comment was not meant to be partial to any tech and targeted toward people starting new in house CDNs, I mentioned ATS as it gives you the best ready to scale platform right now and have no incentives for sharing that knowledge. If your core business is CDN the choice opens up to from scratch or bending something else. Cambridge has shown results that should go an order of magnitude beyond current software [1][2] and a low power FPGA design that I can't find at the moment that would both be a magnitude greater in efficiency than the software mentioned in this thread. In the mean time, using the conventional BSD stack we're closing in on 200gbps on single socket x86 hw and again hitting bus and memory bandwidth limits. [1] https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201408-sigcomm2014-specialization.pdf https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201408... [2] https://www.cl.cam.ac.uk/~rnw24/papers/201708-sigcomm-diskcryptnet.pdf https://www.cl.cam.ac.uk/~rnw24/papers/201708-sigcomm-diskcr...
dormando 9y ago
I worked on the fastly varnish fork. None of this is accurate. Definitely not "because of phk influence". Most of the details are obviously secret, but occasionally when we found something architecturally concerning I'd talk it over with phk in IRC and he would make his own fix. Fastly is a big complex distributed system loosely based on Varnish. There are several fantastic blog posts about Fastly's distributed architectural design, but nothing to my knowledge about anything else. Comparing single-machine scalability is completely inaccurate, mostly because you'll never know what fastly actually did or more importantly why they did it. In general the "big co's fork of X must be superior" is a trope I'm thoroughly tired of.

deleted 9y ago

[deleted]

phkamp 9y ago

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 9y ago
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 9y ago
  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.

rcarmo 9y ago

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 9y ago
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.
amq 9y ago
Nginx and Traefik.
petre 9y ago
Hitch in front of Varnish.

HugoDaniel 9y ago

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.