Hacker News Reader

Comment by batou | Hacker News Reader

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.

View on HN

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.

Indeed. This is good motivation for you:

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.

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.

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

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.

With that track record, there has to be a very good reason to switch.

Reply on news.ycombinator.com