Beef up benchmark suite

[juliangruber]

I'd like to drop the SQLite and Leveled bencharks, as we know we're faster than SQLite and also Leveled, as soon as #95 is done.

Then, add bencharks for all levelup features so we can test streams, encodings and more.

Are you cool with this?

[Raynos]

Is there a database that's faster then leveldb that we should be benchmarking against?

Maybe using leveldb directly with C++ without leveldown. Maybe one of those fast writing databases, Maybe redis.

[juliangruber]

That would be good for demonstration purposes, like, "should I use leveldb for this?".

What I have in mind is to benchmark our own features. When we create a suite that can be run by every database out there, we won't be able to benchmark batch vs. writeStream.

[juliangruber]

Your idea with benchmarking against leveldb in pure C is interesting though. The last time I did this leveled was about 30% slower then pure C which is very good.

[ralphtheninja]

@juliangruber I started on a benchmark repo. All it does atm is to use npm programatically to download all released versions of LevelUP. If you want I could push it to github and we can start from there.

[ralphtheninja]

I'm also not keen on using it to compare against other engines. The most important thing is to measure levelup against itself, so we can notice if anything has happened to the performance. Once we have that up and running, we can start comparing against other engines.

[rvagg]

I guess there are 2 reasons to have benchmarks. We've focused mainly on improving performance over time and avoid performance regressions; this is obviously the most important type of benchmark. But there's also benchmarks that we may want to share with the public, perhaps even on the README--benchmarks against alternative database types.

See this nice page from LevelDB: http://leveldb.googlecode.com/svn/trunk/doc/benchmark.html

The reason I included SQLite3 was because it's a clear alternative choice and it's worth letting people know how it performs. For the record it performs very badly and I suspect the Node wrapper implementers need to address some issues because I don't think it should perform quite as badly as it does; but this information is valuable for people making a choice.

I'm not really sure what other alternatives there are in npm. Perhaps we should benchmark against a JSON file store some how. Maybe we could grab the npm cache file and make a LevelUP version and test reads/searches? It doesn't look like anyone's done a Kyoto wrapper. There's also BerkelyDB that's a contender.

Apparently the only similar embedded store that outperforms LevelDB for standard reads is OpenLDAP Lightning. Although some work has gone into LevelDB since those benchmarks were done I think; particularly the bloom filter (which I think the Basho guys contributed).

Plus, wouldn't it be fun to compare against external storage systems? Perhaps MySQL, Riak & Redis? Those numbers/graphs would be fun and help people make informed choices.

[ralphtheninja]

Once again @rvagg has convinced me otherwise with his wisdom :) The tests need to be engine agnostic (which we already I have I guess, haven't gone through the current benchmark code yet) and they also have to be run in the same environment.

Obviously we can use LevelUP to store the benchmark results, serve the data on the wire and put a nice interface on top of it with some cute graphs etc.

[rvagg]

Oh, and btw, benchmarks against raw LevelDB shouldn't be too hard now that I have the secret sauce to compile against the LevelDOWN binary & includes. It's just a matter of coming up with the test cases and then they can be turned into C++ versions. I'd like to see those numbers, only 30% slower is awesome! I guess that's where Node's multi-threading comes in to play. I wonder if we can improve on that?

[juliangruber]

So we're cool with 2 benchmark suites?

1. bench every levelUp feature and compare between levelUp versions
2. compare levelUp with levelDB, redis, mysql, couch, and more. Here we can/should have both basic things and more real-life use cases. Like get and put but also "give me all the comments that belong to post X" and "fully replicate the database".

[ralphtheninja]

Yep, sounds good.

On 8 March 2013 19:58, Julian Gruber notifications@github.com wrote:

So we're cool with 2 benchmark suites?

1. compare every levelUp feature between levelUp versions
2. compare levelUp with levelDB, redis, mysql, couch, ...

—
Reply to this email directly or view it on GitHubhttps://github.com/rvagg/node-levelup/issues/96#issuecomment-14637461
.

[vweevers]

So we're cool with 2 benchmark suites?

1. bench every levelUp feature and compare between levelUp versions
2. compare levelUp with levelDB, redis, mysql, couch, and more. Here we can/should have both basic things and more real-life use cases. Like get and put but also "give me all the comments that belong to post X" and "fully replicate the database".

Splitting this up:

1. Move levelup benchmarks to level-bench 🆕 (Move benchmarks to Level/bench levelup#652)
2. Add benchmarks for other stores (done, as level-bench takes any)
3. Add (ability to compare against) C++ benchmarks (Add (ability to compare against) C++ benchmarks bench#1)