Posts tagged Caching
Horizontally scaling a web app has become a total no-brainer in the last few years. PaaS offerings like Heroku allow you to add a “dyno” with the click of a button and container technology such as Docker has enabled the same ease to scale your your own deployment. By now it has become a standard in all mayor cloud providers such as AWS to allow you to auto-scale your app.
Given how easy it is to add another container whenever traffic increases and performance starts to take a hit, it is tempting to assume there’s no longer a need for a Memcache. In reality, quite the opposite is true: the more we scale an app horizontally, the more we need and can benefit from caching.
Caching is a technique used in a wide range of contexts to increase the performance of storage systems. For example, modern microprocessors all have fast cache memory built into them, so that repeated accesses to the same memory addresses come from the fast cache storage, rather than from the slower main memory. In a similar way, operating systems maintain a cache of disk buffers in main memory, so that repeated reads from the same disk blocks come from the cached data rather than needing to be read from disk, which is much slower than memory.
The same kinds of considerations apply to caching for web and mobile applications with Memcache. In this case, it’s common to cache the results of database queries, partial page renders, or the results of other application-specific computations.
In any caching application, there are two questions that have to be answered. First, “What should I cache?” and second, “How big a cache do I need?”.
In many cases, the answer to the first question is determined by the web framework you use. For example, Django, Laravel, Spring Boot and others all have integrated caching systems that simplify the caching of database query results and HTML page renders. These frameworks usually also expose a lower-level API for doing application-specific custom caching.
However, the second question is trickier. At MemCachier, we get questions about cache sizing from customers all the time. Fortunately, there is a simple and systematic way to go about choosing a cache size, which we’re going to describe in this article.
Memcache is a technology that improves the performance and scalability of web apps and mobile app backends. It can alleviate bottlenecks such as slow database queries or high CPU usage. This is in contrast to horizontal scaling where all resources are multiplied and can easily lead to overprovisioning a particular resource such as network bandwidth. Memcache helps you scale by alleviating a pressed resource and is thus a perfect addition to your scaling toolbox to optimize resource consumption.
When it comes to adding Memcache to your applications you have several options. You can, for example, just set up your own Memcached server. However, if you are a developer that loves building apps and are wary of setting and manage your own Memcached server, chances are you have stumbled upon ElastCache. This might seem like a better option since you only need to tell ElastiCache what instances you want, how many of them you want, and it will set up a Memcached cluster for you.
Unfortunately, with ElastiCache you’re still stuck needing to directly dealing with instances. There should be an easier way! Enter MemCachier, a SaaS offering for managed Memcache. With just a click of a button you get a cache in any the size you want. Simplicity, however, is just the tip of the iceberg in terms of benefits a SaaS offering can provide. At MemCachier, we wanted to not only make Memcache simpler, but also to make it better.
One great MemCachier feature is built-in support for consistent hashing. Consistent hashing ultimately gives you better hit ratios when servers in your cache are either added or removed. In this post we’ll explain consistent hashing and show you why you should care.