4 ms·

According to Redis themselves, a high end and well tuned redis server will get you ~200k requests per second[1]. This is if all your application does is send re

According to Redis themselves, a high end and well tuned redis server will get you ~200k requests per second[1]. This is if all your application does is send requests in a loop. Am I correct that redis does not offer a native API and so forces you to craft commands as strings? Just having to run snprintf 500k per second wastes a considerable amount of CPU. Combined with the normal overhead of communicating over a socket, using redis is going to be considerably slower than just keeping that memory in your own process. That's assuming the overhead of the redis internals is 0. [1] https://redis.io/topics/benchmarks https://redis.io/topics/benchmarks

kgeist 5y ago
In the article, they say: >The service we switched from Go to Rust is the “Read States” service. Its sole purpose is to keep track of which channels and messages you have read >On cache key eviction, we commit your Read States to the database. We also schedule a database commit for 30 seconds in the future whenever a Read State is updated. So it's a separate service whose only purpose is to store data in-memory with occasional commits to persisted DB, which sounded a lot like Redis. But of course, a special optimized service is always going to outperform a general purpose tool such as Redis. They also replaced HashMaps with BTreeMaps, reduced the number of memory copies they were doing, etc. -- which has nothing to do with Go, but also contributed to a performance increase
Karrot_Kream 5y ago
The trick is to precompute the Redis command strings whenever possible. We (not going to name names here) use Redis at above that scale. Our keys all have a fixed size, so we preallocate a buffer that can hold the command and the key, clear (so move the write pointer back to the beginning of the key) it on every new request, write directly into the buffer, and then pass a pointer to the buffer when writing to the socket. This is a similar trick we use whenever we're constructing load tests as a lot of the time can be spent creating request bodies instead of just pushing bytes onto the socket as fast as possible.
- jacquesm 5y ago
  That sounds like it is written in highly optimized C, not in Rust?
  - Karrot_Kream 5y ago
    You can do this in Rust with a mut pointer into the string. You can even do it in Go with a byte buffer. Lots of languages give you the tools to do stuff like this if you look. I hear Python's StringIO does similar things but I'm not as familiar with Pythons runtime in these situations.
Matthias247 5y ago
What is a native API? Sending string commands and parsing the response is as much of an API as a HTTP API is. It's not a library interface if you mean that - but that always applies for distributed systems.
- dahfizz 5y ago
  Yeah, by native API I meant a native library that would allow you to call into redis directly. Native being the qualifier - as opposed to an HTTP API, which is not native.

kgeist 5y ago

In the article, they say: >The service we switched from Go to Rust is the “Read States” service. Its sole purpose is to keep track of which channels and messages you have read >On cache key eviction, we commit your Read States to the database. We also schedule a database commit for 30 seconds in the future whenever a Read State is updated. So it's a separate service whose only purpose is to store data in-memory with occasional commits to persisted DB, which sounded a lot like Redis. But of course, a special optimized service is always going to outperform a general purpose tool such as Redis. They also replaced HashMaps with BTreeMaps, reduced the number of memory copies they were doing, etc. -- which has nothing to do with Go, but also contributed to a performance increase

Karrot_Kream 5y ago

The trick is to precompute the Redis command strings whenever possible. We (not going to name names here) use Redis at above that scale. Our keys all have a fixed size, so we preallocate a buffer that can hold the command and the key, clear (so move the write pointer back to the beginning of the key) it on every new request, write directly into the buffer, and then pass a pointer to the buffer when writing to the socket. This is a similar trick we use whenever we're constructing load tests as a lot of the time can be spent creating request bodies instead of just pushing bytes onto the socket as fast as possible.

jacquesm 5y ago
That sounds like it is written in highly optimized C, not in Rust?
- Karrot_Kream 5y ago
  You can do this in Rust with a mut pointer into the string. You can even do it in Go with a byte buffer. Lots of languages give you the tools to do stuff like this if you look. I hear Python's StringIO does similar things but I'm not as familiar with Pythons runtime in these situations.

Matthias247 5y ago

What is a native API? Sending string commands and parsing the response is as much of an API as a HTTP API is. It's not a library interface if you mean that - but that always applies for distributed systems.

dahfizz 5y ago
Yeah, by native API I meant a native library that would allow you to call into redis directly. Native being the qualifier - as opposed to an HTTP API, which is not native.