Add separate read connection for server and batch share inserts #15
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@mar-v-in @sisou @fiaxh @styppo
This PR:
PoolServer
for a read-only endpoint. This is extremely important for database scalability, because while read endpoints can be duplicated, write endpoints cannot. The current implementation forces using the same endpoint for reading and writing, meaning the pool owner must use the write endpoint for both reading and writing, and therefore must scale vertically (renting larger servers) rather than horizontally (renting more servers).This ran in production today against over 22,000 connected devices pummeling the servers. Here's the CPU graph of my write DB endpoint before applying my update (left) and after (right):
Notice that before the change:
And after the change:
Additionally, here's a snapshot of the databases under the load of 22,000 devices. Note the number of queries/sec for the write endpoint (top) vs the read endpoint (bottom):
I don't have a screenshot, but prior to this patch these numbers were almost reversed: 95% of the queries ran against the write endpoint (the other 5% being my API endpoint which uses
pool_info
and only calculates stats for the website).This is an extremely important distinction, again, because if the read endpoints get overloaded they can replicate and split their work, where the write endpoint cannot.