-
Notifications
You must be signed in to change notification settings - Fork 25
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
Switch to long running tasks for the multiplexer #344
base: main
Are you sure you want to change the base?
Conversation
We could probably have a single low res TimerHandle that resets on each loop and has a 10s leeway to re-arm. So we ensure we cancel both read/write tasks within timeout+10s. That we we aren't churning timer handles EDIT: with the task overhead gone, that is where all the time gets spent |
That test fails locally before and after this change so I think its intent is to overload the queue but its too fast now, and my local machine is too fast as well before the change. The queue size needs to be patched to be smaller so it can be overrun before it can be processed |
Maybe a RangedTimeout that does a callback on timeout |
Previously it only waited for the multiplexer to close but the task would still be finishing up. This became obvious after the assertion hit in NabuCasa#340
Performance improvements:
RangedTimeout
reduced the number of created TimerHandles by ~94% while accessing the UI by~2x performance improvement for small packets (common case) https://codspeed.io/NabuCasa/snitun/branches/bdraco%3Along_running_tasks
Some considerations
While these changes are designed for the client side, this combination of these changes is expected significantly increase the number of active connections a serve can handle at one time.
Instead of creating many small tasks, create two long running ones for the reader/writer to avoid flooding the event loop with tasks when the connection is generating many packets.
This is still a bit of a WIP, but should be deferred until after a release with #303 so they get separate release cycles
implement back pressure Implement pause and resume requests for a channel #353
download multi gig file
Known issues