You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Right now all requests are accepted from a single thread, which then adds them to a queue and a thread from the thread-pool will then take that request and actually handle it.
This however means, that there is always the memory allocation for the queue + the locks/mutexes needed for synchronising the accesses to set queue.
Describe the solution you'd like
Use the SO_REUSEPORT flag in unix to have each thread in the thread-pool listening on its own socket. The connectons are automatically split up between the different sockets, so that will not be something we need to worry about.
Each thread can then accept a connection and handle the request directly by itself, which should be at least a bit faster.
Additional context
This not only allows the application to accept multiple connections at the same moment, because they are split, but also reduces the memory allocations and use of locks/mutexes in the queue, which could otherwise become a real performance bottleneck, which itself could otherwise not really be removed or optimized in any meaningful way.
When trying to implement this, there were some unexpected problems and because of them, this has been put on hold for now.
It might be revisited in the future, but there is no garantue for it right now.
Is your feature request related to a problem? Please describe.
Right now all requests are accepted from a single thread, which then adds them to a queue and a thread from the thread-pool will then take that request and actually handle it.
This however means, that there is always the memory allocation for the queue + the locks/mutexes needed for synchronising the accesses to set queue.
Describe the solution you'd like
Use the
SO_REUSEPORT
flag in unix to have each thread in the thread-pool listening on its own socket. The connectons are automatically split up between the different sockets, so that will not be something we need to worry about.Each thread can then accept a connection and handle the request directly by itself, which should be at least a bit faster.
Additional context
This not only allows the application to accept multiple connections at the same moment, because they are split, but also reduces the memory allocations and use of locks/mutexes in the queue, which could otherwise become a real performance bottleneck, which itself could otherwise not really be removed or optimized in any meaningful way.
Resources
man
stack exchange thread
The text was updated successfully, but these errors were encountered: