|
|
|
|
|
|
by andrewstuart2
3142 days ago
|
|
|
Microservices need to be divided up very carefully, with full knowledge of the latency trade-off of moving functionality across a network gap. A same-datacenter round-trip takes 5,000 times longer than a main memory access, and 1,000,000 times longer than an L1 cache access. There's no silver bullet in performance or scalability. Each solution will require trading off advantages that matter less to achieve business goals. Here are a few references that leap to mind (I keep the first printed out and pinned right next to my monitor). https://gist.github.com/jboner/2841832 https://www.quora.com/What-are-some-mind-blowing-facts-about... |
|
|
This is a ridiculous comparison though. When have you ever seen a situation where a micro service was accessed over the network to fetch something that would have been in L1 cache? And yes, having a value "in memory" is faster, but in most cases these days things aren't "in memory", they're "in memory in memcached, somewhere in the cluster, probably not on the local server so you have to go over the network anyway".
Just out of curiosity though, I tested on our network. Our RTT between servers is less than half a millisecond. Our fastest service can get a cached reply back to the calling service in 35ms, whereas many calls are >100ms and some are much longer (e.g. initial login calls). It would take a lot of external login calls to noticeably (to the user) increase even the fastest service.
We also use Redis and memcached, and spread those across other services. Excluding specifically HTTP overhead and just looking at network latency, a few memcached calls which hit non-local servers in the cluster cost us as much in latency as one HTTP call would.