Love this part. I wonder how much of the complexity of microservices and various cloud services are actually adding value on a net basis vs. resume-driven development of some bored backend engineer.
Love this part. I wonder how much of the complexity of microservices and various cloud services are actually adding value on a net basis vs. resume-driven development of some bored backend engineer.
Edit: I'd be curious how they hold up to a redis `flush all` or memcached `flush_all`. I wonder if they've ever game day'd such a scenario.
Populate the cache as part of the startup sequence.
Some cool info about SO
From 2019
> Layers of Cache at Stack Overflow
> We have our own “L1”/”L2” caches here at Stack Overflow, but I’ll refrain from referring to them that way to avoid confusion with the CPU caches mentioned above. What we have is several types of cache. Let’s first quickly cover local and memory caches here for terminology before a deep dive into the common bits used by them:
> “Global Cache”: In-memory cache (global, per web server, and backed by Redis on miss)
> Usually things like a user’s top bar counts, shared across the network
> This hits local memory (shared keyspace), and then Redis (shared keyspace, using Redis database 0)
> “Site Cache”: In-memory cache (per site, per web server, and backed by Redis on miss)
> Usually things like question lists or user lists that are per-site
> This hits local memory (per-site keyspace, using prefixing), and then Redis (per-site keyspace, using Redis databases)
> “Local Cache”: In-memory cache (per site, per web server, backed by nothing)
> Usually things that are cheap to fetch, but huge to stream and the Redis hop isn’t worth it
> This hits local memory only (per-site keyspace, using prefixing)
and
> For the curious, some quick stats from last Tuesday (2019-07-30) This is across all instances on the primary boxes (because we split them up for organization, not performance…one instance could handle everything we do quite easily):
> Our Redis physical servers have 256GB of memory, but less than 96GB used.
- 1,586,553,473 commands processed per day (3,726,580,897 commands and 86,982 per second peak across all instances – due to replicas)
- Average of 2.01% CPU utilization (3.04% peak) for the entire server (< 1% even for the most active instance)
- 124,415,398 active keys (422,818,481 including replicas)
- Those numbers are across 308,065,226 HTTP hits (64,717,337 of which were question pages)
https://nickcraver.com/blog/2019/08/06/stack-overflow-how-we...
It is hard to make a high-growth startup selling co-located servers whose docs page is a link to Linux documentation and RFCs.