Asyncore poller efficiency #1380

Open
opened 2018-10-28 09:01:35 +01:00 by PeterSurda · 0 comments
PeterSurda commented 2018-10-28 09:01:35 +01:00 (Migrated from github.com)

Asyncore pollers initialise the poller objects for every poll. This causes inefficiency when using a huge number of connections. It's only necessary to do it this way for the select poller, the others can reuse an old object. To fix this requires some refactoring, instead of performing a check and set/reset for every connection for every poll, the set/reset can be done when the write or read buffer get updated. This reduces the number of checks as well as syscalls. I managed to get a prototype working on one of the bootstrap servers, and it reduced the CPU usage of the asyncore loop by a factor of 6. However it needs more work as it was only done with the epoll poller, and I had to disable the bandwidth limit functionality.

Asyncore pollers initialise the poller objects for every poll. This causes inefficiency when using a huge number of connections. It's only necessary to do it this way for the select poller, the others can reuse an old object. To fix this requires some refactoring, instead of performing a check and set/reset for every connection for every poll, the set/reset can be done when the write or read buffer get updated. This reduces the number of checks as well as syscalls. I managed to get a prototype working on one of the bootstrap servers, and it reduced the CPU usage of the asyncore loop by a factor of 6. However it needs more work as it was only done with the epoll poller, and I had to disable the bandwidth limit functionality.
This repo is archived. You cannot comment on issues.
No Milestone
No project
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2024-12-19#1380
No description provided.