This works fine for static content, but it doesn't work for dynamic content. As sites move quickly to provide personalization and real-time content, the performance burden has migrated back to the server farm, causing renewed increase in response times and availability issues.
ESI is one solution to the performance problems surrounding dynamic caching. What ESI adoption could mean to enterprises is a reduction in hardware and software maintenance costs in the data center and a shifting of responsibility back out to the caching industry. It also must be accepted by developers, who have to learn and implement the technology. This is a drawback because caching has traditionally been transparent and local dynamic caching solutions are in-line with that trend. Whether ESI gains widespread use in time to boost the faltering service-based caching industry remains to be seen. But in the meantime, it's definitely a technology worth knowing about.
Most dynamic content is published via ASP (Active Server Pages), JSP (Java Server Pages), PHP (recursive acronym for PHP: Hypertext Preprocessor) or CGI (Common Gateway Interface) applications, such as PERL scripts that interact with a database where the actual content is stored. The recent wave of personalization and portals on the Internet meant migrating a large portion of Web page content back into the database with an accompanying increase in the use of server-side technologies. While this model is much easier from a development perspective and provides a richer, more interactive experience for the user, this dynamic content cannot be accommodated by traditional caching technologies.
Not only must dynamic content be created by the origin server, but it must also be formatted and delivered to the browser, incurring disk I/O, network and memory overhead when using server-side modules to process requests, perform database queries and format data before delivery back to the browser. Consider a Web page that includes the daily news. Each request must be passed to the origin server because that news is generally stored in a database or even in a file that cannot be cached as it's constantly changing.
In response to this situation, many makers of cache devices (and of load-balancers supporting cache redirects) proudly boast that their products pass requests for dynamic content directly to the origin servers rather than to the cache first. This is good because it reduces the time taken to get to the origin server. But it's also not so good because it puts more strain on the origin server as there's more for that server to process. Web servers are therefore once again burdened by serving content and processing requests and browsers.
ESI is a method of describing noncachable and cachable content to speed the delivery of dynamic content. Most important, ESI also contains an invalidation protocol that lets the origin server or content-management system of an organization indicate to the edge-side cache that it needs to update content.
Consider again our Web page containing the daily news. In the big picture, the news item is dynamic, but it is not necessarily personalized. This item is cachable for a certain period of time and could plausibly be stored within the edge cache for that time and updated only when the news expires, as indicated by the origin server or content-management system. The ESI specification offers a method of storing and invalidating the content at the edge-side caches, thereby providing functionality to relieve the vast amount of traffic and process for certain types of dynamic content.
RSS
