Server-side Caching in Web Applications
Performance optimization is one of the main highlighted topics in web application development. As we all know, every second and every bit that transfer between/ among components is very important. Enhancement of a very tiny step or process in a server may drastically reduce the overall response time. Most of the time the web servers need to communicate with third-party APIs, databases or other external services. Each and every single communication between the server and other component costs in terms of time and money. When the growth of the application usage, this cost will be a considerable huge amount. Cashing is one of the main technique that can be applied to reduce the cost of the webservers.
What is Caching?
Caching is the concept of saving commonly/ frequently used data in memory (inside or near to the server) and use them on behalf of the actual data source when the same types of operations or data are requested.
Let us have a simple example, imagine we have a simple server and database which can retrieve data according to requests.
If user roles for each user have stored in the database. For role-based authentication mechanisms, each and every request need to fetch the user role from the database (there are several other mechanisms as well). In this case, we can use cache to temporarily store the data inside the cache without frequent querying the user roles from the database. It helps to reduce the occurrence of the same network call again and again to the database.
Let us assume there is a function that takes more computational power when it uses (Eg: finding a number of users who have admin privileges), we can store the results of this kind of functions in the cache to avoid re-computations.
And also, If there are multiple servers are trying to access the database at the same time, we can reduce the database load by using cache.
If so, why we cannot store the whole database context inside the cache 😁
For caching, it needs to use solid-state drives (SSD) as memories. When the database grows, the cost will be exponentially increasing if we use cache to store all the data. And also, if the size of the data inside the cache increased, the searching time inside the cache also get increased. So there is a threshold limit that can grow the cache according to the application context.
Cache Access Patterns
There are several patterns that can use to access cash throughout application operations.
- Write through- If new write command comes to the server, it will update both database and cache at the same time going through cache. If one of them fails, the process will be rollbacked.
- Write around- If new write command comes to the server, it will directly write on the database and return the acknowledgement without updating the cache. The cache will be updated in a further time when the first ‘’miss’’ occurred.
- Write back- If new write command comes to the server it will update only the cache and send the acknowledgement back. It has another service to write the cache updates to the database. The main drawback of this technique is if the database writes error occurred while the background service running to update the database user will not acknowledge that.
Cache Placement Methods
- In-memory Cache (Local Cache)- Use a part of RAM in the server as cache. In this case, the additional space needed to RAM for caching purpose. However, this approach is useful only for small-scale applications. With the application growth and if the number of servers increases, this method will not be useful anymore.
- Global cache- Used external instance connected to the server as cache. When the number of server instances is increased, still these types of global caches can facilitate data consistency. The size of the cache can be increase independently of the severs. When it comes to distributed cashing methodologies global caches are broadly involved.
Cache Replacement Policies
There is a number of cache replacement policies are available in modern caching libraries. But the thing is, this cache replacement policy is directly affected the application performance. Choosing the right cache replacement policy is very important. Let us discuss some common cache replacement policies.
- Least recently used (LRU)- When cache referring new or existing entry it keeps on the top of the list and keeps track of what are the most recently used items in the cache. When registering a new entry to the cache, it discards the least recently used entry and appends the new entry to the top of the list.
- Most recently used (MRU)- This works somewhat similar to the LRU, but this keeps track of the lowest recently used entries. When a new entry comes to the cache, it discards the most recently used entry from the cache and registers a new entry to the cache.
- Least frequently used (LFU)- According to this policy, it considers the frequency of each entry inside the cache. When a new entry registers to the cache, it searches for the lowest frequently used entry from the cache and discard it to save the new entry.
Apart from these policies, there are some more commonly used cache replacement policies that can use for different scenarios.
Things need to be the focus on before designing a system with a cache
Mainly we use caches due to cost reduction aspects in terms of time and money. The main tip is the “cache replacement policy” that we can obtain the real benefit of caching. Having a poor cache replacement policy leads to get less optimized output from caching and also Sometimes it may double your cost.
The increased hit rate of the cache should be the main goal when we choosing the cache replacement policy. If we choose a poor cache replacement policy, the server has to process redundant call to cache and also when it needs to find it from original source as well. In these cases, the cost will be higher than the actual that we had before used a cache.
Also, we need to consider the memory size what we use as a cache. If we use a very smaller cache, It will have to read and write entries more frequently to the cache and it leads to more cost than we expected. We have to maintain medium-scale cache memory in terms of memory capacity.
Choose the right cache access pattern also very important to maintain data consistency in the cashing system. The cache access pattern is depending on your application type and domain. There is no perfect access pattern. So the system designer needs to choose the best pattern according to the application context.
Conclusion
Caching is one of the main technique that can be used in the performance enhancement of a web application. When we use caching techniques in our applications, we have to properly design accessing patterns, the size of the cache that we need to use and the cache replacement policy in deeply to get real benefits from the cache.
