Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switching socket model #65

Open
Lol3rrr opened this issue Jun 17, 2020 · 1 comment
Open

Switching socket model #65

Lol3rrr opened this issue Jun 17, 2020 · 1 comment
Labels
enhancement New feature or request wontfix This will not be worked on

Comments

@Lol3rrr
Copy link
Owner

Lol3rrr commented Jun 17, 2020

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

@Lol3rrr Lol3rrr added the enhancement New feature or request label Jun 17, 2020
@Lol3rrr
Copy link
Owner Author

Lol3rrr commented Jun 18, 2020

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.

@Lol3rrr Lol3rrr added the wontfix This will not be worked on label Jun 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant