Inboxes, API usage quotas, and a few other truly global things live here.A "global cache," which is shared amongst all sites and servers.This resides in Redis (in a distinct DB, purely for easier debugging).
Most cached values go here, things like hot question id lists and user acceptance rates are good examples.A "site cache," which can be accessed by any instance (on any server) of a single site.This resides purely in memory, no network or DB access.Contains things like user sessions, and pending view count updates.A "local cache," which can only be accessed from 1 server/site pair.NET 4.5's GZip implementation is a lot betterĬonceptually, each site has 3 distinct caches: We've gotten a little smarter and only compress things that actually get smaller compressed (which requires some calisthenics when reading keys), and.We also have plenty of CPU time to spare on the web tier, especially in the NY datacenter.Most of our cached values are strings, so even at low CPU usage we get great compression ratios.We compress values* before sending them to Redis.Naturally, the fastest # of bytes to send across a network is 0.We keep a "L1" cache (basically, HttpRuntime.Cache) of recently set/read values on a server.This is not surprising, really, if you think about it.
In our (admittedly limited) experience, Redis is so fast that the slowest part of a cache lookup is the time spent reading and writing bytes to the network. Prior to the NY move our Redis instance was in a virtual machine on a (lightly loaded) web tier machine. Kyle recently mentioned the specs of the machine in passing. Perhaps more interesting, we use Redis as a caching layer for the entire network. This isn't terribly interesting, but it is terribly fast, though we've recently removed Output Caching from a small number of routes. Virtually all pages accessed by (and subsequently served to) anonymous users are cached, whole cloth, via Output Caching. Oh boy, have I been waiting for somebody to ask something like this.
0 kommentar(er)
