3 ms·

I also see the update in response to this comment, and it puts everything into perspective. You haven't changed the meaning of "write done," you have just been

I also see the update in response to this comment, and it puts everything into perspective. You haven't changed the meaning of "write done," you have just been comparing your reciprocal throughput against Redis's latency, and I think you have been confusing those two. "600 ns" then really means "1.6M QPS of throughput," which is a good number but is well within the capabilities of many similar offerings (including several databases that are truly persistent). It also says nothing about your latency. If you want to say you are 2-6x faster than Redis, you are going to have to compare that number to Redis's throughput.

mehrant 2y ago
Reading your comment about comparing the throughput to Redis, it seems to me that you haven't read the benchmark article really. In there, we're in fact comparing the "throughput" and not the latency. allow me to quote some of the throughput numbers from the article mentioned above: Single Operation Performance Redis Single Operations SET: 273,672.69 requests per second (p50=0.095 ms) GET: 278,164.12 requests per second (p50=0.095 ms) HPKV Single Operations INSERT: 1,082,578.12 operations per second GET: 1,728,939.43 operations per second DELETE: 935,846.09 operations per second Batch Operation Performance Redis Batch Operations SET: 2,439,024.50 requests per second (p50=0.263 ms) GET: 2,932,551.50 requests per second (p50=0.223 ms) HPKV Batch Operations INSERT: 6,125,538.03 operations per second GET: 8,273,300.27 operations per second DELETE: 5,705,816.00 operations per second The latency of 600ns as I mentioned is a local vectored interface call and not over the network. the is not how we compared the system with Redis. the above numbers are using our RIOC API over the network, in which HPKV behaves like a server similar to a Redis server. The numbers above are compared with Redis in-memory and HPKV is still 2-6x faster. even if you assume HPKV as just an in-memory KV store with no persistence.

mehrant 2y ago

Reading your comment about comparing the throughput to Redis, it seems to me that you haven't read the benchmark article really. In there, we're in fact comparing the "throughput" and not the latency. allow me to quote some of the throughput numbers from the article mentioned above: Single Operation Performance Redis Single Operations SET: 273,672.69 requests per second (p50=0.095 ms) GET: 278,164.12 requests per second (p50=0.095 ms) HPKV Single Operations INSERT: 1,082,578.12 operations per second GET: 1,728,939.43 operations per second DELETE: 935,846.09 operations per second Batch Operation Performance Redis Batch Operations SET: 2,439,024.50 requests per second (p50=0.263 ms) GET: 2,932,551.50 requests per second (p50=0.223 ms) HPKV Batch Operations INSERT: 6,125,538.03 operations per second GET: 8,273,300.27 operations per second DELETE: 5,705,816.00 operations per second The latency of 600ns as I mentioned is a local vectored interface call and not over the network. the is not how we compared the system with Redis. the above numbers are using our RIOC API over the network, in which HPKV behaves like a server similar to a Redis server. The numbers above are compared with Redis in-memory and HPKV is still 2-6x faster. even if you assume HPKV as just an in-memory KV store with no persistence.