Could you add Valkey to the benchmark? Curious about different key-types too, like list and hash. Also, big values (2KB) and small values (<256B)

▲

esafak 4 hours ago | parent | next [-]

And MS Garnet.

	▲	murtazayusuf 3 hours ago \| parent [-]
		that will be part of the next benchmark run, my previous run showed kividb was head to head with Garnet, it was not better but also wasn't worse either. But I haven't tested it with kividb 1.1.0 yet

▲

murtazayusuf 4 hours ago | parent | prev [-]

I did run a benchmark against Valkey 9.1.2 with --io-threads 8 earlier, I will rerun it soon, but these were the results from the previous run, I haven’t been able to find someone who can independently verify these so if you would like then please proceed:

At 100 B GET and pipeline 16, valkey is at 1.61M against 19.71M ops/s for kividb. For 1 KB GET, pipeline 16 it was 1.44M against 8.95M and at 100 B GET, no pipelining: 0.99M against 3.11M, but at pipeline 1 the load generator was the limit for the fast engines, so that row undersells all of them

Values were 100 B and 1 KB, so the small case is covered but not 2 KB. That run only did strings and MSET and MGET. lists and hashes aren't in it yet. Both are a fair ask, and I'll add 2 KB values and LPUSH/LRANGE and HSET/HGETALL scenarios to the harness for the next run.

▲

edoceo 4 hours ago | parent [-]

This seems a reasonable response but was [dead] so I vouched you. Was dead because it's BS or wrong or...?

	▲	murtazayusuf 36 minutes ago \| parent \| next [-]
		And thanks for vouching for me, not sure why it was marked as dead
	▲	murtazayusuf 3 hours ago \| parent \| prev [-]
		Thanks edoceo, this benchmark was run on an earlier version of kividb, which still had several memory management issues, for example, in this test, the memory per key was around 250B as compared to 178B for redis, so probably that's why, I have not been able to publish these numbers yet, but since several people have raised this, I will be prioritizing it