3 ms·

> He even admits Postgres maxxed out its 2 cores, but Redis was bottlenecked by the HTTP server. What exactly is your point? That you can further optimize eith

> He even admits Postgres maxxed out its 2 cores, but Redis was bottlenecked by the HTTP server. What exactly is your point? That you can further optimize either option? Well yes, that comes at no suprise. I mean, the latencies alone are in the range of some transcontinental requests. Were you surprised that Redis outperformed Postgres? I hardly think so. So what's the problem? The main point that's proven is that there is indeed diminishing returns in terms of performance. For applications where you can afford an extra 20ms when hitting a cache, caching using a persistent database is an option. For some people, it seems this fact was very surprising. That's food for thought, isn't it?

hvb2 1y ago
I've done this many times in AWS leveraging dynamodb. Comes with ttl support (which isn't precise so you still need to check expiration on read), and can support long TTLs as there's essentially no limit to the storage. All of this at a fraction of the cost of HA redis Only if you need that last millisecond of performance and have done all other optimizations should one consider redis imho
- motorest 1y ago
  > I've done this many times in AWS leveraging dynamodb. Exactly. I think nosql offerings from any cloud provider already supports both TTL and conditional requests out-of-the-box, and the performance of basic key-value CRUD operations is often <10ms. I've seem some benchmarks advertise memory cache services as having latencies around 1ms. Yeah, this would mean the latency of a database is 10 times higher. But relative numbers matter nothing. What matters is absolute numbers, as they are the ones that drive tradeoff analysis. Does a feature afford an extra 10ms in latency, and is that performance improvement worth paying a premium?
- re-thc 1y ago
  > All of this at a fraction of the cost of HA redis This depends on your scale. Dynamodb is pay per request and the scaling isn’t as smooth. At certain scales Redis is cheaper. Then if you don’t have high demand maybe it’s ok without HA for Redis and it can still be cheaper.
  - motorest 1y ago
    > At certain scales Redis is cheaper. Can you specify in which scenario you think Redis is cheaper than caching things in, say, dynamodb.
    - odie5533 1y ago
      High read/write and low-ish size. Also it's faster.
      - motorest 1y ago
        > High read/write and low-ish size. Also it's faster You posted a vague and meaningless assertion. If you do not have latency numbers and cost differences, you have absolutely nothing to show for, and you failed to provide any rationale that justified even whether any cache is required at all.
        odie5533 1y ago
        At 10k RPS you'll see a significant cost savings with Redis over DynamoDB. ElastiCache Serverless (Redis/Memcached): Typical latency is 300–500 microseconds (sub-millisecond response) DynamoDB On-Demand: Typical latency is single-digit milliseconds (usually between 1–10 milliseconds for standard requests)
        motorest 1y ago
        > At 10k RPS you'll see a significant cost savings with Redis over DynamoDB. You need to be more specific than that. Depending on your read/write patterns and how much memory you need to allocate to Redis, back of the napkin calculations still point to the fact that Redis can still cost >$1k/month more than DynamoDB. Did you actually do the math on what it costs to run Redis?
        hvb2 1y ago
        > At 10k RPS You would've used local memory first. At which point I cannot see getting to those request levels anymore > ElastiCache Serverless (Redis/Memcached): Typical latency is 300–500 microseconds (sub-millisecond response) Sure > DynamoDB On-Demand: Typical latency is single-digit milliseconds (usually between 1–10 milliseconds for standard requests) I know very little use cases where that difference is meaningful. Unless you have to do this many times sequentially in which case optimizing that would be much more interesting than a single read being .5 ms versus the typical 3 to 4 for dynamo (that last number is based on experience)

hvb2 1y ago

I've done this many times in AWS leveraging dynamodb. Comes with ttl support (which isn't precise so you still need to check expiration on read), and can support long TTLs as there's essentially no limit to the storage. All of this at a fraction of the cost of HA redis Only if you need that last millisecond of performance and have done all other optimizations should one consider redis imho

motorest 1y ago
> I've done this many times in AWS leveraging dynamodb. Exactly. I think nosql offerings from any cloud provider already supports both TTL and conditional requests out-of-the-box, and the performance of basic key-value CRUD operations is often <10ms. I've seem some benchmarks advertise memory cache services as having latencies around 1ms. Yeah, this would mean the latency of a database is 10 times higher. But relative numbers matter nothing. What matters is absolute numbers, as they are the ones that drive tradeoff analysis. Does a feature afford an extra 10ms in latency, and is that performance improvement worth paying a premium?
re-thc 1y ago
> All of this at a fraction of the cost of HA redis This depends on your scale. Dynamodb is pay per request and the scaling isn’t as smooth. At certain scales Redis is cheaper. Then if you don’t have high demand maybe it’s ok without HA for Redis and it can still be cheaper.
- motorest 1y ago
  > At certain scales Redis is cheaper. Can you specify in which scenario you think Redis is cheaper than caching things in, say, dynamodb.
  - odie5533 1y ago
    High read/write and low-ish size. Also it's faster.
    - motorest 1y ago
      > High read/write and low-ish size. Also it's faster You posted a vague and meaningless assertion. If you do not have latency numbers and cost differences, you have absolutely nothing to show for, and you failed to provide any rationale that justified even whether any cache is required at all.
      - odie5533 1y ago
        At 10k RPS you'll see a significant cost savings with Redis over DynamoDB. ElastiCache Serverless (Redis/Memcached): Typical latency is 300–500 microseconds (sub-millisecond response) DynamoDB On-Demand: Typical latency is single-digit milliseconds (usually between 1–10 milliseconds for standard requests)
        motorest 1y ago
        > At 10k RPS you'll see a significant cost savings with Redis over DynamoDB. You need to be more specific than that. Depending on your read/write patterns and how much memory you need to allocate to Redis, back of the napkin calculations still point to the fact that Redis can still cost >$1k/month more than DynamoDB. Did you actually do the math on what it costs to run Redis?
        hvb2 1y ago
        > At 10k RPS You would've used local memory first. At which point I cannot see getting to those request levels anymore > ElastiCache Serverless (Redis/Memcached): Typical latency is 300–500 microseconds (sub-millisecond response) Sure > DynamoDB On-Demand: Typical latency is single-digit milliseconds (usually between 1–10 milliseconds for standard requests) I know very little use cases where that difference is meaningful. Unless you have to do this many times sequentially in which case optimizing that would be much more interesting than a single read being .5 ms versus the typical 3 to 4 for dynamo (that last number is based on experience)