4 ms·
The author is pretty inconsistent here. They make good points when mentioning all the problems with benchmarking and how it's a bad idea to fixate on a specific
by joosters 7y ago
The author is pretty inconsistent here. They make good points when mentioning all the problems with benchmarking and how it's a bad idea to fixate on a specific, narrow problem - but then, go on to complain about specific, narrow problems, using them to build a narrative about how linux/whatever is flawed.
A specific example: the part about how epoll() is broken because of its design, and how it causes 'thundering herd' issues when using multiple threads/processes. I had plenty of experience with epoll from over ten years ago, and it wasn't a problem even back then. Multiple processes listening on the same socket did not all wake up when a new connection came in. Sure, why not bring up specific issues with Apache, but there are plenty of other web servers that work very well (nginx, etc) and have existed for over a decade.
- rachelbythebay 7y agogunicorn (Python, in case you’re lucky enough to not have run across it) forks after creating listener socket(s). Every child does the epoll thing. When awakened, they all call accept4 and then all but one gets -1. This happens right now and “powers” a stupid amount of the economy. And it’s wasteful.
- joosters 7y agoOur old mechanism was a parent process that created the listen sockets, and then sent the FDs to the previously-created child processes. (The children would be registering their FDs with epoll and then calling accept() themselves) That never seemed to trigger the problem.
- pstrateman 7y agoThe issue is whether they're using level or edge triggering with epoll. With level you won't miss events, with edge if you have a process crash you might. It's a trade off.