Hibernate Caching

Introduction

Hibernate is a high-performance, object/relational persistence and query service, but it won't solve all the performance issues without a little help. Hence we use the concept of Caching here. Caching is mainly used for optimizing database applications and is designed to reduce the traffic between our application and the database by conserving data already loaded from database. This article will give you the overview of Hibernate Caching mechanisms.

Hibernate Caching

By implementing Caching, the application will work with the data in the cache most of the time. Whenever there is a request for data that is not cached, the database will be contacted. So obviously the access time and traffic will be reduced between the application and the database. Here the cache stores only the data related to current running application. In order to do that, the cache must be cleared time to time whenever the applications are changing.

Hibernate uses two different caches for objects: first-level cache and second-level cache

First-Level Cache

• First Level cache is associated with session object.
• Hibernate uses first level cache within a single transaction boundary and also uses this by default.
• This is mainly used to reduce the number of SQL queries it needs to generate within a given transaction. For Example, if an object is modified several times within the same transaction, Hibernate will generate only one SQL UPDATE at the end, containing all the modifications.

Second-Level Cache

• Second level cache always associates with the session factory Object.
• It keeps loaded objects at the session factory level across the transaction boundaries.
• These objects are available to the whole application, not just to the user running the query. This way, each time a query returns an object that is already loaded in the cache; one or more database transactions potentially are avoided.
• The second-level cache holds on to the 'data' for all properties and associations (and collections if requested) for individual entities that are marked to be cached.

Query-Level Cache

• It can be used if we need to cache actual query results, rather than just persistent objects.
• It does not cache the state of the actual entities in the result set; it caches only identifier values and results of value type. So the query cache should always be used in conjunction with the second-level cache.

Caching Implementations

Hibernate comes with a number of built-in integrations with open-source cache providers. Each cache provides different capacities in terms of performance, memory use, and configuration possibilities. Some of them are listed below.

EHCache (Easy Hibernate Cache)

• Ehcache is a widely used java distributed cache for general purpose caching, Java EE and light-weight containers.
• Provider class : org.hibernate.cache.EhCacheProvider
• It is a fast, lightweight, and easy-to-use in-process cache.
• supports read-only and read/write caching and memory- and disk-based caching
• It does not support clustering

OSCache (Open Symphony Cache)

• OSCache is a caching solution that includes a JSP tag library and set of classes to perform fine grained dynamic caching of JSP content, servlet responses or arbitrary objects.
• Provider class : org.hibernate.cache.OSCacheProvider
• Provides caching functionalities for JSP pages or arbitrary objects.
• Also supports read-only and read/write caching, and memory- and disk-based caching
• Provides basic support for clustering via either Java Groups or JMS.

SwarmCache

• SwarmCache is a simple cluster-based caching solution based on JavaGroups.
• It uses IP multicast to efficiently communicate with any number of hosts on a LAN
• Provider class: org.hibernate.cache.SwarmCacheProvider
• Supports read-only or nonstrict read/write caching
• It is specifically designed for use by clustered, database-driven web applications. Such applications typically have many more read operations than write operations, which allows SwarmCache to deliver the greatest performance gains

JBoss TreeCache

• It provides enterprise-grade clustering solutions to Java-based frameworks, application servers or custom-designed Java SE applications.
• Is a powerful replicated (synchronous or asynchronous) and transactional cache
• Provider class: org.hibernate.cache.TreeCacheProvider
• useful when we need a true transaction-capable caching architecture

Configuration

Configuration of a particular caching mechanism is specified in the hibernate.cfg.xml file as in the below example.

<hibernate-configuration>

<session-factory>

...

<property name="hibernate.cache.provider_class">

org.hibernate.cache.EHCacheProvider

</property>

...

</session-factory>

</hibernate-configuration>

The name in <property> tag must be hibernate.cache.provider_class for activating second-level cache. We can use hibernate.cache.use_second_level_cache property, which allows you to activate and deactivate the second-level cache. By default, the second-level cache is activated and uses the EHCache.

Caching Strategies

It is very important to select the specific Caching strategy after selecting the particular cache implementation. Because none of the cache providers support all of the cache concurrency strategies. The following four caching strategies are available:

• Read-only: This strategy is useful for data that is read frequently but never updated. This is by far the simplest and best-performing cache strategy. Here is an example for using the read-only cache strategy.

<class name="abc.mutable” mutable="true ">

<cache usage="read-only"/>

....

</class>

• Read/write: Read/write caches may be appropriate if your data needs to be updated. They carry more overhead than read-only caches. In non-JTA environments, each transaction should be completed when Session.close () or Session.disconnect () is called. Here is an example for using the read-write cache strategy.

<class name="abc.xyz" .... >

<cache usage="read-write"/>

….

<set name="yuv" ... >

<cache usage="read-write"/>

….

</set>

</class>

• Nonstrict read/write: This strategy does not guarantee that two transactions won't simultaneously modify the same data. Therefore, it may be most appropriate for data that is read often but only occasionally modified. An example for NonStrict read-write cache strategy,

<class name="abc.xyz" .... >

<cache usage=" nonstrict-read-write"/>

……

</class>

• Transactional: This is a fully transactional cache that may be used only in a JTA environment.

The caching strategy options available for different cache implementations are described in the following table.

Cache	Read-Only	NonStrict Read/ Write	Read/Write	Transactional
EHCache	Yes	Yes	Yes	No
OSCache	Yes	Yes	Yes	No
SwarmCache	Yes	Yes	No	No
JBoss TreeCache	Yes	No	No	Yes

Conclusion

Hibernate has a flexible and powerful way of implementing caching mechanisms which will be very helpful in improving the performance of web applications which incorporate heavy database traffics. It should be implemented using an incremental, test-driven approach. When done correctly, a small amount of well executed caching can boost our applications to their maximum capacities.

References

• http://www.hibernate.org/
• http://www.javabeat.net/
• http://www.javalobby.org
• http://ehcache.sourceforge.net
• http://www.jboss.org/jbosscache/
• http://www.devx.com

Read More

Hibernate Caching

Introduction

Hibernate is a high-performance, object/relational persistence and query service, but it won't solve all the performance issues without a little help. Hence we use the concept of Caching here. Caching is mainly used for optimizing database applications and is designed to reduce the traffic between our application and the database by conserving data already loaded from database. This article will give you the overview of Hibernate Caching mechanisms.

Hibernate Caching

By implementing Caching, the application will work with the data in the cache most of the time. Whenever there is a request for data that is not cached, the database will be contacted. So obviously the access time and traffic will be reduced between the application and the database. Here the cache stores only the data related to current running application. In order to do that, the cache must be cleared time to time whenever the applications are changing.

Hibernate uses two different caches for objects: first-level cache and second-level cache

First-Level Cache

• First Level cache is associated with session object.
• Hibernate uses first level cache within a single transaction boundary and also uses this by default.
• This is mainly used to reduce the number of SQL queries it needs to generate within a given transaction. For Example, if an object is modified several times within the same transaction, Hibernate will generate only one SQL UPDATE at the end, containing all the modifications.

Second-Level Cache

• Second level cache always associates with the session factory Object.
• It keeps loaded objects at the session factory level across the transaction boundaries.
• These objects are available to the whole application, not just to the user running the query. This way, each time a query returns an object that is already loaded in the cache; one or more database transactions potentially are avoided.
• The second-level cache holds on to the 'data' for all properties and associations (and collections if requested) for individual entities that are marked to be cached.

Query-Level Cache

• It can be used if we need to cache actual query results, rather than just persistent objects.
• It does not cache the state of the actual entities in the result set; it caches only identifier values and results of value type. So the query cache should always be used in conjunction with the second-level cache.

Caching Implementations

Hibernate comes with a number of built-in integrations with open-source cache providers. Each cache provides different capacities in terms of performance, memory use, and configuration possibilities. Some of them are listed below.

EHCache (Easy Hibernate Cache)

• Ehcache is a widely used java distributed cache for general purpose caching, Java EE and light-weight containers.
• Provider class : org.hibernate.cache.EhCacheProvider
• It is a fast, lightweight, and easy-to-use in-process cache.
• supports read-only and read/write caching and memory- and disk-based caching
• It does not support clustering

OSCache (Open Symphony Cache)

• OSCache is a caching solution that includes a JSP tag library and set of classes to perform fine grained dynamic caching of JSP content, servlet responses or arbitrary objects.
• Provider class : org.hibernate.cache.OSCacheProvider
• Provides caching functionalities for JSP pages or arbitrary objects.
• Also supports read-only and read/write caching, and memory- and disk-based caching
• Provides basic support for clustering via either Java Groups or JMS.

SwarmCache

• SwarmCache is a simple cluster-based caching solution based on JavaGroups.
• It uses IP multicast to efficiently communicate with any number of hosts on a LAN
• Provider class: org.hibernate.cache.SwarmCacheProvider
• Supports read-only or nonstrict read/write caching
• It is specifically designed for use by clustered, database-driven web applications. Such applications typically have many more read operations than write operations, which allows SwarmCache to deliver the greatest performance gains

JBoss TreeCache

• It provides enterprise-grade clustering solutions to Java-based frameworks, application servers or custom-designed Java SE applications.
• Is a powerful replicated (synchronous or asynchronous) and transactional cache
• Provider class: org.hibernate.cache.TreeCacheProvider
• useful when we need a true transaction-capable caching architecture

Configuration

Configuration of a particular caching mechanism is specified in the hibernate.cfg.xml file as in the below example.

<hibernate-configuration>

<session-factory>

...

<property name="hibernate.cache.provider_class">

org.hibernate.cache.EHCacheProvider

</property>

...

</session-factory>

</hibernate-configuration>

The name in <property> tag must be hibernate.cache.provider_class for activating second-level cache. We can use hibernate.cache.use_second_level_cache property, which allows you to activate and deactivate the second-level cache. By default, the second-level cache is activated and uses the EHCache.

Caching Strategies

It is very important to select the specific Caching strategy after selecting the particular cache implementation. Because none of the cache providers support all of the cache concurrency strategies. The following four caching strategies are available:

• Read-only: This strategy is useful for data that is read frequently but never updated. This is by far the simplest and best-performing cache strategy. Here is an example for using the read-only cache strategy.

<class name="abc.mutable” mutable="true ">

<cache usage="read-only"/>

....

</class>

• Read/write: Read/write caches may be appropriate if your data needs to be updated. They carry more overhead than read-only caches. In non-JTA environments, each transaction should be completed when Session.close () or Session.disconnect () is called. Here is an example for using the read-write cache strategy.

<class name="abc.xyz" .... >

<cache usage="read-write"/>

….

<set name="yuv" ... >

<cache usage="read-write"/>

….

</set>

</class>

• Nonstrict read/write: This strategy does not guarantee that two transactions won't simultaneously modify the same data. Therefore, it may be most appropriate for data that is read often but only occasionally modified. An example for NonStrict read-write cache strategy,

<class name="abc.xyz" .... >

<cache usage=" nonstrict-read-write"/>

……

</class>

• Transactional: This is a fully transactional cache that may be used only in a JTA environment.

The caching strategy options available for different cache implementations are described in the following table.

Cache	Read-Only	NonStrict Read/ Write	Read/Write	Transactional
EHCache	Yes	Yes	Yes	No
OSCache	Yes	Yes	Yes	No
SwarmCache	Yes	Yes	No	No
JBoss TreeCache	Yes	No	No	Yes

Conclusion

Hibernate has a flexible and powerful way of implementing caching mechanisms which will be very helpful in improving the performance of web applications which incorporate heavy database traffics. It should be implemented using an incremental, test-driven approach. When done correctly, a small amount of well executed caching can boost our applications to their maximum capacities.

References

• http://www.hibernate.org/
• http://www.javabeat.net/
• http://www.javalobby.org
• http://ehcache.sourceforge.net
• http://www.jboss.org/jbosscache/
• http://www.devx.com

Read More

Why Cache the Web?

The short answer is that caching saves money. It saves time as well, which is sometimes the same thing if you believe that "time is money." But how does caching save you money?

It does so by providing a more efficient mechanism for distributing information on the Web. Consider an example from our physical world: the distribution of books. Specifically, think about how a book gets from publisher to consumer. Publishers print the books and sell them, in large quantities, to wholesale distributors. The distributors, in turn, sell the books in smaller quantities to bookstores. Consumers visit the stores and purchase individual books. On the Internet, web caches are analogous to the bookstores and wholesale distributors.

The analogy is not perfect, of course. Books cost money; web pages (usually) don't. Books are physical objects, whereas web pages are just electronic and magnetic signals. It's difficult to copy a book, but trivial to copy electronic data.

The point is that both caches and bookstores enable efficient distribution of their respective contents. An Internet without caches is like a world without bookstores. Imagine 100,000 residents of India each buying one copy of Comics Book from the publisher in India. Now imagine 50,000 Internet users in Australia each downloading the Yahoo! home page every time they access it. It's much more efficient to transfer the page once, cache it, and then serve future requests directly from the cache.

In order for caching to be effective, the following conditions must be met:

• Client requests must exhibit locality of reference.
• The cost of caching must be less than the cost of direct retrieval.

We can intuitively conclude that the first requirement is true. Certain web sites are very popular. Classic examples are the starting pages for Netscape and Microsoft browsers. Others include searching and indexing sites such as Yahoo! and Altavista. Event-based sites, such as those for the Olympics, NASA's Mars Pathfinder mission, and World Cup Soccer, become extremely popular for days or weeks at a time. Finally, every individual has a few favorite pages that he or she visits on a regular basis.

It's not always obvious that the second requirement is true. We need to compare the costs of caching to the costs of not caching. Numerous factors enter into the analysis, some of which are easier to measure than others. To calculate the cost of caching, we can add up the costs for hardware, software, and staff time to administer the system. We also need to consider the time users save waiting for pages to load (latency) and the cost of Internet bandwidth.

Three primary benefits of caching web content:

• To make web pages load faster (reduce latency)
• To reduce wide area bandwidth usage
• To reduce the load placed on origin servers

Types of Web Caches

Web content can be cached at a number of different locations along the path between a client and an origin server. First, many browsers and other user agents have built-in caches. For simplicity, I'll call these browser caches. Next, a caching proxy (a.k.a. "proxy cache") aggregates all of the requests from a group of clients. Lastly, a surrogate can be located in front of an origin server to cache popular responses.

Browser Caches

Browsers and other user agents benefit from having a built-in cache. When you press the Back button on your browser, it reads the previous page from its cache. Nongraphical agents, such as web crawlers, cache objects as temporary files on disk rather than keeping them in memory.

Netscape Navigator lets you control exactly how much memory and disk space to use for caching, and it also allows you to flush the cache. Microsoft Internet Explorer lets you control the size of your local disk cache, but in a less flexible way. Both have controls for how often cached responses should be validated. People generally use 10–100MB of disk space for their browser cache.

A browser cache is limited to just one user, or at least one user agent. Thus, it gets hits only when the user revisits a page. As we'll see later, browser caches can store "private" responses, but shared caches cannot.

Caching Proxies

Caching proxies, unlike browser caches, service many different users at once. Since many different users visit the same popular web sites, caching proxies usually have higher hit ratios than browser caches. As the number of users increases, so does the hit ratio.

Caching proxies are essential services for many organizations, including ISPs, corporations, and schools. They usually run on dedicated hardware, which may be an appliance or a general-purpose server, such as a Unix or Windows NT system. Many organizations use inexpensive PC hardware that costs less than $1,000 / 45000 Rs. At the other end of the spectrum, some organizations pay hundreds of thousands of dollars/ Rupees, or more, for high-performance solutions from one of the many caching vendors.

Caching proxies are normally located near network gateways (i.e., routers) on the organization's side of its Internet connection. In other words, a cache should be located to maximize the number of clients that can use it, but it should not be on the far side of a slow, congested network link.

Caching Proxy Features

The key feature of a caching proxy is its ability to store responses for later use. This is what saves you time and bandwidth. Caching proxies actually tend to have a wide range of additional features that many organizations find valuable. Most of these are things you can do only with a proxy but which have relatively little to do with caching. For example, if you want to authenticate your users, but don't care about caching, you might use a caching proxy product anyway.

Authentication

A proxy can require users to authenticate themselves before it serves any requests. This is particularly useful for firewall proxies. When each user has a unique username and password, only authorized individuals can surf the Web from inside your network. Furthermore, it provides a higher quality audit trail in the event of problems.

Request filtering

Caching proxies are often used to filter requests from users. Corporations usually have policies that prohibit employees from viewing pornography at work. To help enforce the policy, the corporate proxy can be configured to deny requests to known pornographic sites. Request filtering is somewhat controversial. Some people equate it with censorship and correctly point out that filtering schemes are not perfect.

Response filtering

In addition to filtering requests, proxies can also filter responses. This usually involves checking the contents of an object as it is being downloaded. A filter that checks for software viruses is a good example. Some organizations use proxies to filter out Java and JavaScript code, even when it is embedded in an HTML file. I've also heard about software that attempts to prevent access to pornography by searching images for a high percentage of flesh-tone pixels.

For example, see http://www.heartsoft.com, http://www.eye-t.com, and http://www.thebair.com.

Prefetching

Prefetching is the process of retrieving some data before it is actually requested. Disk and memory systems typically use prefetching, also known as "read ahead." For the Web, prefetching usually involves requesting images and hyperlinked pages referenced in an HTML file. Prefetching represents a tradeoff between latency and bandwidth. A caching proxy selects objects to prefetch, assuming that a client will request them. Correct predictions result in a latency reduction; incorrect predictions, however, result in wasted bandwidth. So the interesting question is, how accurate are prefetching predictions? Unfortunately, good measurements are hard to come by. Companies with caching products that use prefetching are secretive about their algorithms.

Translation and transcoding

Translation and transcoding both refer to processes that change the content of something without significantly changing its meaning or appearance. For example, you can imagine an application that translates text pages from English to German as they are downloaded. Transcoding usually refers to low-level changes in digital data rather than high-level human languages. Changing an image file format from GIF to JPEG is a good example. Since the JPEG format results in a smaller file than GIF, they can be transferred faster. Applying general-purpose compression is another way to reduce transfer times. A pair of cooperating proxies can compress all transfers between them and uncompress the data before it reaches the clients.

Traffic shaping

A significant number of organizations use application layer proxies to control bandwidth utilization. In some sense, this functionality really belongs at the network layer, where it's possible to control the flow of individual packets. However, the application layer provides extra information that network administrators find useful. For example, the level of service for a particular request can be based on the user's identification, the agent making the request, or the type of data being requested (e.g., HTML, Postscript, MP3).

Meshes, Clusters, and Hierarchies

There are a number of situations where it's beneficial for caching proxies to talk to each other. There are different names for some different configurations. A cluster is a tightly coupled collection of caches, usually designed to appear as a single service. That is, even if there are seven systems in a cluster, to the outside world it looks like just one system. The members of a cluster are normally located together, both physically and topologically.

A loosely coupled collection of caches is called a hierarchy or mesh. If the arrangement is tree-like, with a clear distinction between upper- and lower-layer nodes, it is called a hierarchy. If the topology is flat or ill-defined, it is called a mesh. A hierarchy of caches make sense because the Internet itself is hierarchical. However, when a mesh or hierarchy spans multiple organizations, a number of issues arise.

List of caching products

Squid

http://www.squid-cache.org

Squid is an open source software package that runs on a wide range of Unix platforms. There has also been some recent success in porting Squid to Windows NT. As with most free software, users receive technical support from a public mailing list. Squid was originally derived from the Harvest project in 1996.

Netscape Proxy Server

http://home.netscape.com/proxy/v3.5/index.html

The Netscape Proxy Server was the first caching proxy product available. The lead developer, Ari Luotonen, also worked extensively on the CERN HTTP server during the Web's formative years in 1993 and 1994. Netscape's Proxy runs on a handful of Unix systems, as well as Windows NT.

Microsoft Internet Security and Acceleration Server

http://www.microsoft.com/isaserver/

Microsoft currently has two caching proxy products available. The older Proxy Server runs on Windows NT, while the newer ISA product requires Windows 2000.

Volera

http://www.volera.com

Volera is a recent spin-off of Novell. The product formerly known as Internet Caching System (ICS) is now called Excelerator. Volera does not sell this product directly. Rather, it is bundled on hardware appliances available from a number of OEM partners.

Network Appliance Netcache

http://www.netapp.com/products/netcache/

Network Appliance was the second company to sell a caching proxy, and the first to sell an appliance. The Netcache products also have roots in the Harvest project.

Inktomi Traffic Server

http://www.inktomi.com/products/network/traffic/

Inktomi boasts some of the largest customer installations, such as America Online and Exodus. Their Traffic Server product has been available since 1997.

CacheFlow

http://www.cacheflow.com

Intelligent prefetching and refreshing features distinguish CacheFlow from their competitors.

InfoLibria

http://www.infolibria.com

InfoLibria's products are designed for high reliability and fault tolerance.

Cisco Cache Engine

http://www.cisco.com/go/cache/

The Cisco 500 series Cache Engine is a small, low-profile system designed to work with their Web Cache Control Protocol (WCCP). As your demand for capacity increases, you can easily add more units.

Lucent imminet WebCache

http://www.lucent.com/serviceprovider/imminet/

Lucent's products offer carrier-grade reliability and active refresh features.

iMimic DataReactor

http://www.imimic.com

iMimic is a relative newcomer to this market. However, their DataReactor product is already licensed to a number of OEM partners. iMimic also sells their product directly.

Read More

Why Cache the Web?

The short answer is that caching saves money. It saves time as well, which is sometimes the same thing if you believe that "time is money." But how does caching save you money?

It does so by providing a more efficient mechanism for distributing information on the Web. Consider an example from our physical world: the distribution of books. Specifically, think about how a book gets from publisher to consumer. Publishers print the books and sell them, in large quantities, to wholesale distributors. The distributors, in turn, sell the books in smaller quantities to bookstores. Consumers visit the stores and purchase individual books. On the Internet, web caches are analogous to the bookstores and wholesale distributors.

The analogy is not perfect, of course. Books cost money; web pages (usually) don't. Books are physical objects, whereas web pages are just electronic and magnetic signals. It's difficult to copy a book, but trivial to copy electronic data.

The point is that both caches and bookstores enable efficient distribution of their respective contents. An Internet without caches is like a world without bookstores. Imagine 100,000 residents of India each buying one copy of Comics Book from the publisher in India. Now imagine 50,000 Internet users in Australia each downloading the Yahoo! home page every time they access it. It's much more efficient to transfer the page once, cache it, and then serve future requests directly from the cache.

In order for caching to be effective, the following conditions must be met:

• Client requests must exhibit locality of reference.
• The cost of caching must be less than the cost of direct retrieval.

We can intuitively conclude that the first requirement is true. Certain web sites are very popular. Classic examples are the starting pages for Netscape and Microsoft browsers. Others include searching and indexing sites such as Yahoo! and Altavista. Event-based sites, such as those for the Olympics, NASA's Mars Pathfinder mission, and World Cup Soccer, become extremely popular for days or weeks at a time. Finally, every individual has a few favorite pages that he or she visits on a regular basis.

It's not always obvious that the second requirement is true. We need to compare the costs of caching to the costs of not caching. Numerous factors enter into the analysis, some of which are easier to measure than others. To calculate the cost of caching, we can add up the costs for hardware, software, and staff time to administer the system. We also need to consider the time users save waiting for pages to load (latency) and the cost of Internet bandwidth.

Three primary benefits of caching web content:

• To make web pages load faster (reduce latency)
• To reduce wide area bandwidth usage
• To reduce the load placed on origin servers

Types of Web Caches

Web content can be cached at a number of different locations along the path between a client and an origin server. First, many browsers and other user agents have built-in caches. For simplicity, I'll call these browser caches. Next, a caching proxy (a.k.a. "proxy cache") aggregates all of the requests from a group of clients. Lastly, a surrogate can be located in front of an origin server to cache popular responses.

Browser Caches

Browsers and other user agents benefit from having a built-in cache. When you press the Back button on your browser, it reads the previous page from its cache. Nongraphical agents, such as web crawlers, cache objects as temporary files on disk rather than keeping them in memory.

Netscape Navigator lets you control exactly how much memory and disk space to use for caching, and it also allows you to flush the cache. Microsoft Internet Explorer lets you control the size of your local disk cache, but in a less flexible way. Both have controls for how often cached responses should be validated. People generally use 10–100MB of disk space for their browser cache.

A browser cache is limited to just one user, or at least one user agent. Thus, it gets hits only when the user revisits a page. As we'll see later, browser caches can store "private" responses, but shared caches cannot.

Caching Proxies

Caching proxies, unlike browser caches, service many different users at once. Since many different users visit the same popular web sites, caching proxies usually have higher hit ratios than browser caches. As the number of users increases, so does the hit ratio.

Caching proxies are essential services for many organizations, including ISPs, corporations, and schools. They usually run on dedicated hardware, which may be an appliance or a general-purpose server, such as a Unix or Windows NT system. Many organizations use inexpensive PC hardware that costs less than $1,000 / 45000 Rs. At the other end of the spectrum, some organizations pay hundreds of thousands of dollars/ Rupees, or more, for high-performance solutions from one of the many caching vendors.

Caching proxies are normally located near network gateways (i.e., routers) on the organization's side of its Internet connection. In other words, a cache should be located to maximize the number of clients that can use it, but it should not be on the far side of a slow, congested network link.

Caching Proxy Features

The key feature of a caching proxy is its ability to store responses for later use. This is what saves you time and bandwidth. Caching proxies actually tend to have a wide range of additional features that many organizations find valuable. Most of these are things you can do only with a proxy but which have relatively little to do with caching. For example, if you want to authenticate your users, but don't care about caching, you might use a caching proxy product anyway.

Authentication

A proxy can require users to authenticate themselves before it serves any requests. This is particularly useful for firewall proxies. When each user has a unique username and password, only authorized individuals can surf the Web from inside your network. Furthermore, it provides a higher quality audit trail in the event of problems.

Request filtering

Caching proxies are often used to filter requests from users. Corporations usually have policies that prohibit employees from viewing pornography at work. To help enforce the policy, the corporate proxy can be configured to deny requests to known pornographic sites. Request filtering is somewhat controversial. Some people equate it with censorship and correctly point out that filtering schemes are not perfect.

Response filtering

In addition to filtering requests, proxies can also filter responses. This usually involves checking the contents of an object as it is being downloaded. A filter that checks for software viruses is a good example. Some organizations use proxies to filter out Java and JavaScript code, even when it is embedded in an HTML file. I've also heard about software that attempts to prevent access to pornography by searching images for a high percentage of flesh-tone pixels.

For example, see http://www.heartsoft.com, http://www.eye-t.com, and http://www.thebair.com.

Prefetching

Prefetching is the process of retrieving some data before it is actually requested. Disk and memory systems typically use prefetching, also known as "read ahead." For the Web, prefetching usually involves requesting images and hyperlinked pages referenced in an HTML file. Prefetching represents a tradeoff between latency and bandwidth. A caching proxy selects objects to prefetch, assuming that a client will request them. Correct predictions result in a latency reduction; incorrect predictions, however, result in wasted bandwidth. So the interesting question is, how accurate are prefetching predictions? Unfortunately, good measurements are hard to come by. Companies with caching products that use prefetching are secretive about their algorithms.

Translation and transcoding

Translation and transcoding both refer to processes that change the content of something without significantly changing its meaning or appearance. For example, you can imagine an application that translates text pages from English to German as they are downloaded. Transcoding usually refers to low-level changes in digital data rather than high-level human languages. Changing an image file format from GIF to JPEG is a good example. Since the JPEG format results in a smaller file than GIF, they can be transferred faster. Applying general-purpose compression is another way to reduce transfer times. A pair of cooperating proxies can compress all transfers between them and uncompress the data before it reaches the clients.

Traffic shaping

A significant number of organizations use application layer proxies to control bandwidth utilization. In some sense, this functionality really belongs at the network layer, where it's possible to control the flow of individual packets. However, the application layer provides extra information that network administrators find useful. For example, the level of service for a particular request can be based on the user's identification, the agent making the request, or the type of data being requested (e.g., HTML, Postscript, MP3).

Meshes, Clusters, and Hierarchies

There are a number of situations where it's beneficial for caching proxies to talk to each other. There are different names for some different configurations. A cluster is a tightly coupled collection of caches, usually designed to appear as a single service. That is, even if there are seven systems in a cluster, to the outside world it looks like just one system. The members of a cluster are normally located together, both physically and topologically.

A loosely coupled collection of caches is called a hierarchy or mesh. If the arrangement is tree-like, with a clear distinction between upper- and lower-layer nodes, it is called a hierarchy. If the topology is flat or ill-defined, it is called a mesh. A hierarchy of caches make sense because the Internet itself is hierarchical. However, when a mesh or hierarchy spans multiple organizations, a number of issues arise.

List of caching products

Squid

http://www.squid-cache.org

Squid is an open source software package that runs on a wide range of Unix platforms. There has also been some recent success in porting Squid to Windows NT. As with most free software, users receive technical support from a public mailing list. Squid was originally derived from the Harvest project in 1996.

Netscape Proxy Server

http://home.netscape.com/proxy/v3.5/index.html

The Netscape Proxy Server was the first caching proxy product available. The lead developer, Ari Luotonen, also worked extensively on the CERN HTTP server during the Web's formative years in 1993 and 1994. Netscape's Proxy runs on a handful of Unix systems, as well as Windows NT.

Microsoft Internet Security and Acceleration Server

http://www.microsoft.com/isaserver/

Microsoft currently has two caching proxy products available. The older Proxy Server runs on Windows NT, while the newer ISA product requires Windows 2000.

Volera

http://www.volera.com

Volera is a recent spin-off of Novell. The product formerly known as Internet Caching System (ICS) is now called Excelerator. Volera does not sell this product directly. Rather, it is bundled on hardware appliances available from a number of OEM partners.

Network Appliance Netcache

http://www.netapp.com/products/netcache/

Network Appliance was the second company to sell a caching proxy, and the first to sell an appliance. The Netcache products also have roots in the Harvest project.

Inktomi Traffic Server

http://www.inktomi.com/products/network/traffic/

Inktomi boasts some of the largest customer installations, such as America Online and Exodus. Their Traffic Server product has been available since 1997.

CacheFlow

http://www.cacheflow.com

Intelligent prefetching and refreshing features distinguish CacheFlow from their competitors.

InfoLibria

http://www.infolibria.com

InfoLibria's products are designed for high reliability and fault tolerance.

Cisco Cache Engine

http://www.cisco.com/go/cache/

The Cisco 500 series Cache Engine is a small, low-profile system designed to work with their Web Cache Control Protocol (WCCP). As your demand for capacity increases, you can easily add more units.

Lucent imminet WebCache

http://www.lucent.com/serviceprovider/imminet/

Lucent's products offer carrier-grade reliability and active refresh features.

iMimic DataReactor

http://www.imimic.com

iMimic is a relative newcomer to this market. However, their DataReactor product is already licensed to a number of OEM partners. iMimic also sells their product directly.

Read More