4 ms·

I agree with respect to traditional architectures but most of our stuff runs from our cache layer (97% of queries are cache hits) so we're moving to lots of sma

by batou 11y ago

I agree with respect to traditional architectures but most of our stuff runs from our cache layer (97% of queries are cache hits) so we're moving to lots of smaller and cheaper instances with a cache front end (memcached). We literally use the database as a storage engine going forward and nothing clever.

redcalx 11y ago
Do you have a view on Redis cache? It seems to be more popular than memcached at the moment.
- batou 11y ago
  Yes. We stick with memcached. Every node in our cluster has an uptime of over 3 years handling up to 5000 requests a second so we're quite happy to leave it. In fact it's the most reliable thing I've ever seen I think. Redis looks nice but I suspect that it may be easy to lean on it too much for functionality. We were looking at it for a couple of tasks but haven't found much motivation to move yet.
  - hvidgaard 11y ago
    With that track record, there has to be a very good reason to switch.
hvidgaard 11y ago
I really wish I could do something like that for our system. We need to hit the database almost every time a query comes in.
- batou 11y ago
  Indeed. This is good motivation for you: http://i.imgur.com/Q8NtKTk.png http://i.imgur.com/Q8NtKTk.png Cache hits versus misses. The latter may result in multiple SQL queries whereas the former are returned from the cache. Imagine the cluster we'd need to support that! That's over 28 days for reference.
  - hvidgaard 11y ago
    It is, but the nature of the application demands that a write query is not considered done until it is guranteed persisted on the disk, and the same data is rarely queried often enough to warrant a dedicated cache layer. The data that is queried often is so far handled by SQL Servers buildin caching gracefully. That isn't the same as we couldn't get some benefit, because we could especially as the userbase scales. But so far we haven't had to scale to the point where it's worth the added complexity to persuit. One can only look forward to the day it is.

by batou 11y ago

redcalx 11y ago

Do you have a view on Redis cache? It seems to be more popular than memcached at the moment.

batou 11y ago
Yes. We stick with memcached. Every node in our cluster has an uptime of over 3 years handling up to 5000 requests a second so we're quite happy to leave it. In fact it's the most reliable thing I've ever seen I think. Redis looks nice but I suspect that it may be easy to lean on it too much for functionality. We were looking at it for a couple of tasks but haven't found much motivation to move yet.
- hvidgaard 11y ago
  With that track record, there has to be a very good reason to switch.

hvidgaard 11y ago

I really wish I could do something like that for our system. We need to hit the database almost every time a query comes in.

batou 11y ago
Indeed. This is good motivation for you: http://i.imgur.com/Q8NtKTk.png http://i.imgur.com/Q8NtKTk.png Cache hits versus misses. The latter may result in multiple SQL queries whereas the former are returned from the cache. Imagine the cluster we'd need to support that! That's over 28 days for reference.
- hvidgaard 11y ago
  It is, but the nature of the application demands that a write query is not considered done until it is guranteed persisted on the disk, and the same data is rarely queried often enough to warrant a dedicated cache layer. The data that is queried often is so far handled by SQL Servers buildin caching gracefully. That isn't the same as we couldn't get some benefit, because we could especially as the userbase scales. But so far we haven't had to scale to the point where it's worth the added complexity to persuit. One can only look forward to the day it is.