Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Updated "Enable SO_REUSEPORT socket option" #1344
Continuing my comment in #1131 (comment) (though nobody comments on mine
Very coincidentally, we actually find a use case where SO_REUSEPORT could benefit our applications.
First, some background:
In the native mechanism of how gunicorn processes sockets, it's very likely many connections are established to a few workers(lwn has stated it's also one of the reasons google implemented SO_REUSEPORT). So we are using the following patch to use SO_REUSEPORT in gunicorn.
Note that when
To answer to @berkerpeksag i think
@wooparadog "when --reuseport is enabled, master process will no longer create listening sockets. " what ? We want to have the master listening on the socket. Workers are only accepting.
yes sorry to not have been clear ...
On Fri, Sep 23, 2016 at 3:49 PM Berker Peksag email@example.com
I might also have not been clear... the following is quoted from the article about Linux's reuseport in lwn
The second of the traditional approaches used by multithreaded servers operating on a single port is to have all of the threads (or processes) perform an accept() call on a single listening socket in a simple event loop of the form:
The problem with this technique, as Tom pointed out, is that when multiple threads are waiting in the accept() call, wake-ups are not fair, so that, under high load, incoming connections may be distributed across threads in a very unbalanced fashion. At Google, they have seen a factor-of-three difference between the thread accepting the most connections and the thread accepting the fewest connections; that sort of imbalance can lead to underutilization of CPU cores. By contrast, the SO_REUSEPORT implementation distributes connections evenly across all of the threads (or processes) that are blocked in accept() on the same port.
Because we are using gunicorn for thrift servers(long connection server). The problem with non-fair accepting is quite serious. However
I'm just giving ideas about how we use gunicorn and
@wooparadog We are in a deep agreement on how useful this option can be :) Like I said,
We might want an option to force the current behaviour (aka "--no-reuseport") but I'm not sure this option is really needed.
Anyway I would accept any patch that do first the check of the reuse_port and use it, and in a specific commit add this possible option to disable it. Thoughts?