The caching of static Web pages at Web proxies is done to reduce page access latency, as well as bandwidth consumption and central processing unit (CPU) load at the Web server. Dynamic Web pages that require server-side processing, a key component of emerging Web applications, cannot be cached using current proxy protocols. The weblet environment described in this paper is one of several solutions being proposed to address this shortcoming.
In this solution, server-side processing is encapsulated as “weblets,” a migratable processing unit. A weblet engine at the Web server and proxy server provides a uniform execution environment for weblets, making it possible to migrate weblets from the Web server and execute them at the proxy server to achieve performance gains. This distinguishes the weblet-based solution from alternate proposals like fragment caches, and industry standards like edge-side include, where the dynamic content of a Web page remains uncacheable.
To enable the weblet-based solution, hypertext transfer protocol (HTTP) needs to be extended to support the processing of weblets, which have the suffix .wlet to distinguish them from conventional Web pages. Web server and proxy server implementations need to be extended to redirect weblet requests to the weblet engine. These extensions have been implemented by the authors via modules in the Apache Web server and the Squid proxy server. A Web cache manager at the proxy server provides the weblet caching mechanism. Currently, the greedy dual-size popularity algorithm is used as the cache replacement policy, and a time to live (TTL)-based cache validation protocol is used to manage weblet consistency.
A key component of the proposed solution is the weblet migration manager, which resides on the Web server and makes decisions about whether weblets should be migrated to the proxy server. It also handles the migration of data objects, in units of database tables, needed for weblet execution. This distinguishes the solution from active cache solutions, where applets (which are similar to weblets) cached at the proxy server are required to access the needed data objects remotely, which may not always be cost-effective.
Migration decisions are based on the types of data objects needed for weblet execution, and their corresponding access patterns. Weblets that do not access data objects are always migrated to the proxy server. Data objects that are mostly read by the client and infrequently updated at the Web server, or those that are frequently updated but not shared with other clients, are always migrated along with their weblets to the proxy server. Data objects that are highly shared and frequently updated are not suitable for migration. Weblets accessing such objects are only migrated if they don’t access such objects frequently, such that the remote data access overhead is not significant.
The weblet environment contains security components to ensure that a proxy server is not compromised by malicious weblets, and that the privacy and integrity of weblets and data objects are not compromised by the proxy server or other malicious weblets. Neither details nor evaluation of these critical components are discussed in this paper, and readers are directed to another publication by the authors.
The performance of weblet-based caching at proxy servers was compared to current Web systems with caching of static pages at proxies, and to the caching of dynamic content at the Web server without proxies. The Transaction Processing Performance Council - Web benchmark (TPC-W), modified to support weblets, with different types of Web interaction workloads, was used for the evaluation. When the Web workload was largely composed of browsing or shopping interactions, weblet-based caching at proxies achieved significantly lower response time, lower CPU use, and better throughput as the number of clients was increased, compared to current Web systems and dynamic content caching. When the workload consisted largely of ordering Web interactions, the performance gains were smaller, due to the fewer migrated weblets. For further evaluation, the performance of the weblet system when caching weblets from different servers at the proxy was compared to a current Web system. The measurements for the browsing interactions workload showed that the weblet system outperformed current Web systems.
The weblet-based proxy caching solution proposed in this paper extends the benefits of proxy caching to dynamic Web content, by providing an environment for the migration of server-side execution and data objects. These features are complementary to other caching solutions being proposed, which can be extended with support for weblets to yield better performance. A critical evaluation of the security issues of the weblet environment is needed. This paper is useful for researchers and developers working on content delivery networks and application servers.
