Storage benchmarks #460
Storage benchmarks #460
Conversation
mrd0ll4r
force-pushed
the
storage-bench
branch
from
2418b21
to
ba982e2
Compare
| func BenchmarkPutDeleteSpreadPeer(b *testing.B) { s.PutDeleteSpreadPeer(b, createNew()) } | ||
| func BenchmarkPutDeleteSpreadInfohash(b *testing.B) { s.PutDeleteSpreadInfohash(b, createNew()) } | ||
| func BenchmarkPutDeleteSpreadInfohashSpreadPeer(b *testing.B) { | ||
| s.PutDeleteSpreadInfohashSpreadPeer(b, createNew()) |
There was a problem hiding this comment.
does gofmt force this into multilines? 😢
There was a problem hiding this comment.
Just tried it in the playground: yep. (I'm running goimports, which I'm pretty sure does the same formatting, but I had to test :) )
| // This uses the same logic as collectGarbage, only that all peers, | ||
| // regardless of age, will be deleted. | ||
| // In the end, only the counter keys remain. | ||
| func (ps *peerStore) Clear() error { |
There was a problem hiding this comment.
Redis has a concept called databases that are similar to schemas in Postgres or MySQL. We could just create a new database and switch to it. Then we don't have to worry about any keys being in the new context.
There was a problem hiding this comment.
I thought about that too! You probably mean we use a database for our stuff, then delete the entire database in Clear(), or even just start a new one for the next benchmark without clearing the old one?
|
Just looked at this again, @jzelinskie can you give me some input on the redis database issue please? |
Fixes #447
This also adds a small variant of the announce and scrape benchmarks.
From the data we gathered from public trackers, swarms are usually tiny (probably only having one peer), and only a handful of swarms are actually big. So I thought it would be nice to see how the storage handles small and large swarms :)