3 ms·
> 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
by 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 agoYou 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.
- kev009 9y agoYes, really, and no, only you and phk have shown this paranoia; most the userbase here agrees by votes. The software I'm discussing is all free open source software and anyone can test for themselves in their own environment to call bullshit. I gain and lose nothing by Varnish being anywhere on the spectrum of good and bad at any aspect of content delivery. I'd hope it would be the best it can be, I don't know what kind of person would wish otherwise. If you got the I/O model I care about right I still couldn't use it (or ATS or any other $newfossproject for reasons stated in response to another person) but I'd be pleased for the professional community. The market is supporting multiple viable open caching applications, those will trivially nibble at commercial CDNs and nothing I say or do is going to change that.. the caching software is not the hardest/most expensive part of operating a global CDN, and many companies will steadfastly solve all those problems for themselves too, and I will again be pleased..