Hi, I'm the original author of this article, though I have since left Pinterest.
180M/s is the peak throughput I've observed from the entire fleet, and is an accurate figure.
It's worth noting that:
(1) When it comes to caching workloads, there is often a wide spread of request amplification factor from a single inbound user request to the site. For example, a search query on Pinterest might internally fan out to an order of magnitude more requests to memcached across several different services along the request path used for servicing that query.
(2) There are many systems outside of the online critical path that use caching, which add load on the system independent of the rate at which users are posting or viewing content on the Pinterest site.
As another reference point, Facebook, who developed mcrouter, shared that their memcached deployment serves on the order of billions of requests per second [0]. And this figure is from 2014; I imagine it's grown a lot since then.
Yeah, 36k per instance (especially on an xlarge or 2xlarge EC2 instance) is well within the serving capacity of memcached. While it depends a lot on the workload profile for a specific cluster, some clusters serve on the order of ~5k/instance while others are as high as ~100k/instance. We've done a lot of experimentation with extstore as well; it certainly eats up more compute cycles on average than an equivalent in-memory only cluster, but is still quite efficient.
Hi, I'm the original author of this article, though I have left Pinterest since this article was published.
Many customers with large AWS footprints, Pinterest included, have enterprise plans with highly custom pricing. It is often the case that general public pricing isn't directly comparable to enterprise pricing on an individual component level.
On the topic of network transfer, many of our highest network bandwidth memcached clusters are replicated with an egress routing policy that exercises an availability zone affinity [0]. For the most efficient clusters, this means that 99.9+% of network bandwidth remains in the client-colocated AZ (within the same region and VPC), which is free [1].
Thanks for the feedback! I have considered creating an interactive installation script, but I figured most users would prefer more precise control over how the application is being installed and configured. I'll consider something like this as a future goal if there is sufficient demand.
Thanks for the bug report! Turns out CodeMirror's HTML and PHP modes require the XML mode to also be loaded as a dependency. This is being tracked in https://github.com/LINKIWI/modern-paste/issues/4 if you're interested in following along.
180M/s is the peak throughput I've observed from the entire fleet, and is an accurate figure.
It's worth noting that:
(1) When it comes to caching workloads, there is often a wide spread of request amplification factor from a single inbound user request to the site. For example, a search query on Pinterest might internally fan out to an order of magnitude more requests to memcached across several different services along the request path used for servicing that query.
(2) There are many systems outside of the online critical path that use caching, which add load on the system independent of the rate at which users are posting or viewing content on the Pinterest site.
As another reference point, Facebook, who developed mcrouter, shared that their memcached deployment serves on the order of billions of requests per second [0]. And this figure is from 2014; I imagine it's grown a lot since then.
[0] https://www.usenix.org/system/files/conference/nsdi13/nsdi13...