Fast Access To Data Is The Primary Purpose Of Caching
Developers have always used data caching to improve application performance. (CPU registers are data caches!) The closer the data is to the application code, the faster the application will run because you avoid the access latency caused by disk and/or network. Local caching is fastest because you cache the data in the same memory as the code itself. Need to render a drop-down list faster? Read the list from the database once, and then cache it in a Java HashMap. Need to avoid the performance-sapping disk trashing of an SQL call to repeatedly render a personalized user’s Web page? Cache the user profile and the rendered page fragments in the user session.
Although local caching is fine for Web applications that run on one or two application servers, it is insufficient if any or all of the following conditions apply:
The data is too big to fit in the application server memory space.
Cached data is updated and shared by users across multiple application servers.
User requests, and therefore user sessions, are not bound to a particular application server.
Failover is required without data loss.
To overcome these scaling challenges, application architects often give up on caching and instead turn to the clustering features provided by relational database management systems (RDBMSes). The problem: It is often at the expense of performance and can be very costly to scale up. So, how can firms get improved performance along with scale and fault tolerance?
Elastic Caching Platforms Balance Performance With Scalability And Availability