3 ms·
I did a small benchmark and found for high concurrency write-only loads, the results of each goroutine writing directly vs using a mutex were basically the same
by LVB 4y ago
I did a small benchmark and found for high concurrency write-only loads, the results of each goroutine writing directly vs using a mutex were basically the same. But things were more interesting when I added a bunch of read goroutines to the mix too (which would be more realistic for e.g. web traffic). In that case, the mutex-protected writes were drastically reduced in favor of reads. And while I have no idea how SQlite is actually handling its locking, it makes intuitive sense that if it doesn't even know about more write load it isn't going to schedule it.
I'm going to clean up the code and post some results in gist, but here is a sample:
Write-only (SQL statements/s):
direct: 45314
w/mutex: 45304
Read/Write mix:
direct: read: 85229 write: 22664
w/mutex: read: 139053 write: 1382
- mappu 4y ago> I did a small benchmark and found for high concurrency write-only loads, the results of each goroutine writing directly vs using a mutex were basically the same. I'm interested to see your gist, but just to note this specific part seems to contradict https://news.ycombinator.com/item?id=33911491 https://news.ycombinator.com/item?id=33911491 , where at 64-wide parallelism for a write-only load, the Go mutex outperforms plain WAL by a factor of ~70x,
- LVB 4y agoThat revised version is indeed interesting. I hope to get things pushed tonight. My approach managed goroutines directly and didn't use the Benchmark parallelism feature. I don't see any obvious reason why that matters but structurally that's a bit different
- LVB 4y agoPretty interesting results by adding SetMaxOpenConns() to Marcus' gist: https://gist.github.com/markuswustenberg/f35ab7e191137dca5f7ec112bfc887be?permalink_comment_id=4396598#gistcomment-4396598 https://gist.github.com/markuswustenberg/f35ab7e191137dca5f7...