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

[WIP] limit starvation on async sockets #941

Closed
wants to merge 2 commits into from

Conversation

minrk
Copy link
Member

@minrk minrk commented Nov 15, 2016

Set async.Socket.starvation_limit = number_of_seconds to put an upper bound on starvation caused by greedy send/recv.

Disable starvation checking with

asyncio.Socket.starvation_limit = 0

Default is 20ms (starvation_limit = 0.02), which has performance impact of 2-5% on this benchmark.

prompted by dabeaz/curio#106

TODO:

  • performance profile
  • compare with simpler count-based limits (msg or byte count?)

limits starvation to 10ms by default

set async.Socket.starvation_limit = number_of_seconds
to put an upper bound on starvation caused by greedy send/recv

Disable starvation checking with asyncio.Socket.starvation_limit = 0
@bluca
Copy link
Member

bluca commented Nov 23, 2016

This PR has suffered from starvation :-) Is it good to go?

@minrk
Copy link
Member Author

minrk commented Nov 24, 2016

No, I'm still investigating whether it's a good idea.

@minrk minrk changed the title limit starvation on async sockets [WIP] limit starvation on async sockets Nov 24, 2016
@dbivolaru
Copy link
Contributor

In more complex applications, if it gets hairy and you have multiple sockets you do want "equal" asyncio scheduling. Sockets which have a lot of data traffic should be scheduled more often (otherwise performance is impacted), so the question is what should happen when everyone gets a lot of data.

That is why I think a size based starvation algorithm would be better for throughput based applications and a message count based starvation algorithm would be better for highly transactional applications. Adding both options so people can choose would not be bad.

The current approach for time based starvation will probably be detrimental for highly transactional applications.

@minrk minrk closed this Jul 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants