4 ms·

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 ni

by 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.
  - phkamp 9y ago
    Well, if you want to "contest most the points in that page." I suggest you do so on substance, rather than by going after the person ? There is a difference between "being ignorant" and "ignoring". I don't think there is much in modern HiPerf computing I'm ignorant of (hint: Guess who's writing one of the most intense HiPerf scientific code right now), but there sure is a lot of it I'm deliberately ignoring with respect to Varnish. TLB flushing, instruction caching ? When your CPU is 50+% idle most of the time, that's not really what (should) worry about. And the "downright difficult job of an OS scheduler" isn't really that hard when all threads a waiting for I/O, wake up for a few microseconds, then go back to waiting for I/O again. And so on, and so forth... Again: Your total lack of actual experience running Varnish shows. You should try it some day, you might actually find it useful :-)
    - kev009 9y ago
      You keep accusing me of logical fallacy but are using them yourself so I can't have a rational conversation with you. There is little CPU idle when you are doing TCP packet pacing, TLS in core, and edge compute. That's what I do on a 30Tbit/s CDN. I was just hoping you might reconsider the thread per connection but it appears not yet. Anyway congrats on the release and have a good day, sorry if the only takeaway you got from this is to be antagonized.
      - phkamp 9y ago
        Thread-per-request seems even more correct to me, given the increased cost of system-calls, now that Spectre and Meltdown fixes are in.
        jeremiep 9y ago
        I used to do thread-per-request, that has mediocre scaling at best. Even on the JVM this barely scales to a few thousand connections; native threads are heavier than that. I've also done a lot of task-per-request (with each thread's affinity locked to a single hardware thread to avoid ripple effects), which does scale at least an order of magnitude more than threads. I now use fiber-per-request for the best of both worlds: the easy sequential model of threads, yet the simple performance of tasks. I can't understand why someone would defend the thread-per-request model at this point. It wasn't even a good model 10 year ago.

by phkamp 9y ago

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.
- phkamp 9y ago
  Well, if you want to "contest most the points in that page." I suggest you do so on substance, rather than by going after the person ? There is a difference between "being ignorant" and "ignoring". I don't think there is much in modern HiPerf computing I'm ignorant of (hint: Guess who's writing one of the most intense HiPerf scientific code right now), but there sure is a lot of it I'm deliberately ignoring with respect to Varnish. TLB flushing, instruction caching ? When your CPU is 50+% idle most of the time, that's not really what (should) worry about. And the "downright difficult job of an OS scheduler" isn't really that hard when all threads a waiting for I/O, wake up for a few microseconds, then go back to waiting for I/O again. And so on, and so forth... Again: Your total lack of actual experience running Varnish shows. You should try it some day, you might actually find it useful :-)
  - kev009 9y ago
    You keep accusing me of logical fallacy but are using them yourself so I can't have a rational conversation with you. There is little CPU idle when you are doing TCP packet pacing, TLS in core, and edge compute. That's what I do on a 30Tbit/s CDN. I was just hoping you might reconsider the thread per connection but it appears not yet. Anyway congrats on the release and have a good day, sorry if the only takeaway you got from this is to be antagonized.
    - phkamp 9y ago
      Thread-per-request seems even more correct to me, given the increased cost of system-calls, now that Spectre and Meltdown fixes are in.
      - jeremiep 9y ago
        I used to do thread-per-request, that has mediocre scaling at best. Even on the JVM this barely scales to a few thousand connections; native threads are heavier than that. I've also done a lot of task-per-request (with each thread's affinity locked to a single hardware thread to avoid ripple effects), which does scale at least an order of magnitude more than threads. I now use fiber-per-request for the best of both worlds: the easy sequential model of threads, yet the simple performance of tasks. I can't understand why someone would defend the thread-per-request model at this point. It wasn't even a good model 10 year ago.