Skip to content
This repository has been archived by the owner on Jan 14, 2022. It is now read-only.

Upgrade dependencies #75

Open
codesections opened this issue Jan 7, 2020 · 0 comments
Open

Upgrade dependencies #75

codesections opened this issue Jan 7, 2020 · 0 comments
Labels
post-1.0 Feature to add after releasing v1.0.0

Comments

@codesections
Copy link
Contributor

Flodgatt is currently using some older versions of its dependencies, as specified in its Cargo.lock file and does not currently build with more recent versions of those dependencies.

This is not a huge issue—since Flodgatt is a binary application rather than a library, it is appropriate to commit the Cargo.lock file to git and for everyone (including TravisCI) to build Flodgatt with the exact versions specified in the lockfile.

Nevertheless, incompatibilities with more up-to-date versions of dependencies prevent us from updating those dependencies and mean that we can't benefit from future upstream performance or security fixes.

@codesections codesections added the post-1.0 Feature to add after releasing v1.0.0 label Mar 20, 2020
codesections added a commit that referenced this issue Apr 9, 2020
This squashed commit makes a fairly significant structural change to significantly reduce Flodgatt's CPU usage.

Flodgatt connects to Redis in a single (green) thread, and then creates a new thread to handle each WebSocket/SSE connection. Previously, each thread was responsible for polling the Redis thread to determine whether it had a message relevant to the connected client. I initially selected this structure both because it was simple and because it minimized memory overhead – no messages are sent to a particular thread unless they are relevant to the client connected to the thread. However, I recently ran some load tests that show this approach to have unacceptable CPU costs when 300+ clients are simultaneously connected.

Accordingly, Flodgatt now uses a different structure: the main Redis thread now announces each incoming message via a watch channel connected to every client thread, and each client thread filters out irrelevant messages. In theory, this could lead to slightly higher memory use, but tests I have run so far have not found a measurable increase. On the other hand, Flodgatt's CPU use is now an order of magnitude lower in tests I've run.

This approach does run a (very slight) risk of dropping messages under extremely heavy load: because a watch channel only stores the most recent message transmitted, if Flodgatt adds a second message before the thread can read the first message, the first message will be overwritten and never transmitted. This seems unlikely to happen in practice, and we can avoid the issue entirely by changing to a broadcast channel when we upgrade to the most recent Tokio version (see #75).
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
post-1.0 Feature to add after releasing v1.0.0
Projects
None yet
Development

No branches or pull requests

1 participant