3 ms·
It seems like this could help solve the thundering herd problem [0][1][2], no? [0] http://en.wikipedia.org/wiki/Thundering_herd_problem http://en.wikipedia.org
by MalcolmEvershed 13y ago
It seems like this could help solve the thundering herd problem [0][1][2], no?
[0] http://en.wikipedia.org/wiki/Thundering_herd_problem http://en.wikipedia.org/wiki/Thundering_herd_problem
[1] http://stackoverflow.com/questions/15636319/why-is-accept-mutex-on-as-default-in-nginx http://stackoverflow.com/questions/15636319/why-is-accept-mu...
[2] http://uwsgi-docs.readthedocs.org/en/latest/articles/SerializingAccept.html http://uwsgi-docs.readthedocs.org/en/latest/articles/Seriali...
- wmf 13y agoProblem was already solved: "In modern times, the vast majority of UNIX systems have evolved, and now the kernel ensures (more or less) only one process/thread is woken up on a connection event."
- MalcolmEvershed 13y agoI believe that quote from [2] is referring to simply calling accept(), but modern socket servers use epoll() (or similar) before accept() which I think still has the problem (because I've run strace on nginx and uwsgi and I'm pretty sure I saw all processes wake-up from epoll()). So I'm thinking that with SO_REUSEPORT, each server process would have a different socket to epoll() on, and the kernel would only wake-up one process on a new connection, thus, solving the thundering herd problem for modern servers.