mirror of
https://github.com/matze/wastebin.git
synced 2026-04-25 08:36:00 +03:00
[GH-ISSUE #156] Improve performance by not locking the database #91
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/wastebin-matze#91
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mokurin000 on GitHub (Apr 6, 2025).
Original GitHub issue: https://github.com/matze/wastebin/issues/156
In my testing branch human-readable-perf, I replaced the current
Arc<Mutex<Connection>>pattern with a background thread receiving a command and a oneshot channel, to send result backAnd the replacement will increase average performance of insertion by 12.5%, see report-.zip generated by
wastebin-bench.The main cost is readability of the code (I did not find a design not such ugly for now)
As it's just for performance test, only
insertis implemented in the -perf branch.@mokurin000 commented on GitHub (Apr 6, 2025):
Alternatively, we may also replace
self.connto athread_local!storagedConnection(Obviously we need not multiple database instances inside one wastebin server instance). Thus, mutex is no longer needed, and the code could stay clean. Performance should be similar with the flume based solution.@matze commented on GitHub (Apr 6, 2025):
Can you re-run the test on a single-core machine/VM/container? Just to see the impact of how tokio's background threads deal in such situation compared to a dedicated one.
@mokurin000 commented on GitHub (Apr 6, 2025):
I will do so when I am avaliable
BTW I found a command could limit the process to run with single CPU core
@mokurin000 commented on GitHub (Apr 7, 2025):
In the single-core scene, there is no difference between the kanel version and the spawn_blocking version;
20472 vs 20770 QPS, latter is of the spawn_blocking version
In multi-core scene (14c20t), kanel version is 11% faster:
45458 QPS vs 50274.89 QPS
Thanks to @qaqland, with a generic call() method we could have performance gain without big refactor work
@matze commented on GitHub (Apr 12, 2025):
Is it also in your branch? Sorry for being late, this week has been a bit scarce regarding time.
@mokurin000 commented on GitHub (Apr 14, 2025):
Hi! Sorry for slow response
Yeah, I have implemented it in https://github.com/mokurin000/wastebin/tree/human-readable-perf-kanal
I tried to cherry-pick the performance patch, but there are too many conflicts, it's now based on the human-readable branch
@matze commented on GitHub (May 17, 2025):
Can you try this branch and check the results? It's a similar design but uses a bog standard
mpscchannel. On my system I see even better improvements of around 45% rather than 12.5%.@mokurin000 commented on GitHub (May 18, 2025):
nice work!
my kanal implementation sends boxed closures, which is more expensive than sending commands, but requires less work.
we may also try to replace tokio mpsc channel with kanal ones? That is the fastest channel currently
@mokurin000 commented on GitHub (May 18, 2025):
Strange... on my i7-12700H, running on Arch 6.14.6
Is that due to CPU difference?
For benchmarking, my parameters are 5 secs warmup and 30 secs bench
@matze commented on GitHub (May 18, 2025):
Perhaps. I get wildly different results on an i7-13700H (20 threads): 16209.17 (master) vs 24695.38 (mpsc) vs 33287.72 (kanal). And differences become smaller for smaller user numbers. So yeah, I will go for kanal even though it's yet another dependency :-/
Another difference is that my implementation runs the database handler in a
spawn_blockingthread that is managed by tokio and both server listener and database handler futures are scheduled withfutures_concurrency'sjoin()rather than spawning a tokio task.@matze commented on GitHub (May 18, 2025):
One last thing: these huge numbers are of course only possible with an in-memory database. These changes do not do much when the disk is hammered with writes. But in any case, a lot more reads than writes is probably the norm for a pastebin.