congrats. performance-wise it does not look like the best but durability and consistency would be the key points.
> default 128 MB memory limit on kvlds.
this can be changed i suppose? i hope docs will be coming.
> services requests upon it from a single connection; and a request multiplexer (mux) which accepts multiple connections and routes requests and responses to and from a single "upstream" connection.
does this mean it support multiple requests in one round-trip?
Show me a networked data store which does better on the same hardware. (FWIW, with trivial keys and values, kivaloo gets significantly more operations per second.)
default 128 MB memory limit on kvlds. this can be changed i suppose? i hope docs will be coming.
Command-line option to kvlds, documented in a text file in the kivaloo tarball.
services requests upon it from a single connection; and a request multiplexer (mux) which accepts multiple connections and routes requests and responses to and from a single "upstream" connection. does this mean it support multiple requests in one round-trip?
Yes, and responses can come back out-of-order, too.
i didn't get what you mean by networked data store. afaik almost all of kv stores are similar wrt "network".
i checked http://redis.io/topics/benchmarks and saw that kivaloo performs better within given constraints like value limit at 255 bytes. your benchmark page makes numbers worse because of that 128 mb option.
i didn't get what you mean by networked data store.
As opposed to a library like BDB.
your benchmark page makes numbers worse because of that 128 mb option.
I assumed that people would get "ok, here's the in-core performance, and here's the out-of-core performance" and understand that where that drop happens is a function of how much RAM they use. I suppose I should re-run the benchmarks with kivaloo set to use 1.5 GB of RAM.
kvlds is single-connection. Using mux you can have as many connections as you want, and they can send whatever requests they want -- mux doesn't care what the requests are, and as far as kvlds is concerned, all the requests are coming from the same place.
Comments
congrats. performance-wise it does not look like the best but durability and consistency would be the key points.
> default 128 MB memory limit on kvlds. this can be changed i suppose? i hope docs will be coming.
> services requests upon it from a single connection; and a request multiplexer (mux) which accepts multiple connections and routes requests and responses to and from a single "upstream" connection. does this mean it support multiple requests in one round-trip?
performance-wise it does not look like the best
Show me a networked data store which does better on the same hardware. (FWIW, with trivial keys and values, kivaloo gets significantly more operations per second.)
default 128 MB memory limit on kvlds. this can be changed i suppose? i hope docs will be coming.
Command-line option to kvlds, documented in a text file in the kivaloo tarball.
services requests upon it from a single connection; and a request multiplexer (mux) which accepts multiple connections and routes requests and responses to and from a single "upstream" connection. does this mean it support multiple requests in one round-trip?
Yes, and responses can come back out-of-order, too.
i didn't get what you mean by networked data store. afaik almost all of kv stores are similar wrt "network".
i checked http://redis.io/topics/benchmarks and saw that kivaloo performs better within given constraints like value limit at 255 bytes. your benchmark page makes numbers worse because of that 128 mb option.
i didn't get what you mean by networked data store.
As opposed to a library like BDB.
your benchmark page makes numbers worse because of that 128 mb option.
I assumed that people would get "ok, here's the in-core performance, and here's the out-of-core performance" and understand that where that drop happens is a function of how much RAM they use. I suppose I should re-run the benchmarks with kivaloo set to use 1.5 GB of RAM.
Nice! Btw, on concurrency, is it multiple reader/single writer?
kvlds is single-connection. Using mux you can have as many connections as you want, and they can send whatever requests they want -- mux doesn't care what the requests are, and as far as kvlds is concerned, all the requests are coming from the same place.