ThankGodItsHoliday

reasons that Web caches are used:

To reduce latency – Because the request is satisfied from the cache (which is closer to the client) instead of the origin server, it takes less time for it to get the representation and display it. This makes the Web seem more responsive.

To reduce network traffic – Because representations are reused, it reduces the amount of bandwidth used by a client. This saves money if the client is paying for traffic, and keeps their bandwidth requirements lower and more manageable.

Type of web cache
1.Browser Caches

This cache is especially useful when users hit the ‘back’ button or click a link to see a page they’ve just looked at. Also, if you use the same navigation images throughout your site, they’ll be served from browsers’ caches almost instantaneously.

Web proxy caches

work on the same principle, but a much larger scale. Proxies serve hundreds or thousands of users in the same way; large corporations and ISPs often set them up on their firewalls, or as standalone devices (also known as intermediaries).

Proxy caches are a type of shared cache; rather than just having one person using them, they usually have a large number of users, and because of this they are very good at reducing latency and network traffic. That’s because popular representations are reused a number of times.

Gateway Caches

Also known as ‘reverse proxy caches’ or ’surrogate caches,’ gateway caches are also intermediaries, but instead of being deployed by network administrators to save bandwidth, they’re typically deployed by Webmasters themselves, to make their sites more scalable, reliable and better performing.

How Web Caches Work

1. If the response’s headers tell the cache not to keep it, it won’t.
2. If no validator (an ETag or Last-Modified header) is present on a response, it will be considered uncacheable.
3. If the request is authenticated or secure (ex https), it won’t be cached.
4. A cached representation is considered fresh (that is, able to be sent to a client without checking with the origin server) if:
* It has an expiry time or other age-controlling header set, and is still within the fresh period.
* If a browser cache has already seen the representation, and has been set to check once a session.
* If a proxy cache has seen the representation recently, and it was modified relatively long ago.
5. Fresh representations are served directly from the cache, without checking with the origin server.
6. If an representation is stale, the origin server will be asked to validate it, or tell the cache whether the copy that it has is still good.

and .htaccess cache

Here is how cache technique implement in real world application, WordPress – Super cache (Digg from WP supercache) : scope in technical points

WP Super Cache is a static caching plugin for WordPress. It generates html files that are served directly by Apache without processing comparatively heavy PHP scripts. By using this plugin you will speed up your WordPress blog significantly.

How it works

A classic method of preparing an under powered site for a Digg front page appearance or a Slashdotting has been to manually save copies of dynamically generated pages, and place them in directories that match the permalinks structure. This method of performance enhancement does help servers handle a higher load without crashing, but is only effective when an oncoming rush of traffic can be anticipated. WP-Cache alone, while helpful, is not adequate in many cases, so WP Super Cache was created to effectively mimic the manual page caching method, but to handle it in an automated fashion.

When a visitor who is not logged in, or who has not left a comment, visits they will be served a static HTML page out of the supercache subdirectory within the WordPress cache directory. If you navigate to that directory you can view an exact replica of your permalink structure as well as the HTML files within the directories.

To determine if a page has been cached, view the source and the last lines on the page should read something like

You’ll only see the last line if compression is enabled.

If you have compression enabled it is no longer possible to determine which cache the page was served from without looking at the page headers. Pages served from the WP-Cache “half on” cache will have an extra header.

WP-Super-Cache: WP-Cache

There are many ways of viewing the headers.
With compression disabled, the text will be displayed at the end of the page if the page is served from the static Supercache.

* Normal WP-Cache files are now split in two. Meta files go in their own directory making it much faster to scan and update the cache.
* Includes this WP-Cache and protected posts fix.
* As Akismet and other spam fighting tools have improved, the cache will only be invalidated if a comment is definitely not spam.
* A “lock down” button. I like to think of this as my “Digg Proof” button. This basically prepares your site for a heavy digging or slashdotting. It locks down the static cache files and doesn’t delete them when a new comment is made.
* Supercache static files can be regenerated while serving a slightly out of date file. This will significantly lower the load on a busy server with lots of traffic and comments. Think of it as an automatic “lock down mode” for every page on your site.
* Automatic updating of your .htaccess file. (Backup your .htaccess before installing the plugin!)
* Don’t super cache any request with GET parameters.
* Properly serve cached static files on Red Hat/Cent OS systems or others that have an entry for gzip in /etc/mime.types.

Caveats

* If you’re logged in or have left a comment you’ll never see a super-cached page. You’ll see plain old regular WP-Cached pages instead. That’s not so bad since a huge majority of your visitors will never leave a comment.
* Mod Rewrite is used to serve the static HTML pages. As fancy permalinks is also a requirement it should already be installed.
* Some of the more dynamic aspects of your site’s template won’t refresh quite as quickly. For example, recent comment sidebar plugins. Those plugin should use Javascript to load their content instead.
* Some sites have problems serving compressed html files and need extra configuration.
* Don’t expect a cheap hosting plan to survive a major traffic spike, even if it is cached!
* Remember that dynamic content such as that within the sidebar, will only refresh when the cached pages are refreshed. This timeout value can be modified, but cached files will only be removed if you have a healthy mix of static and dynamic requests.

For the cache guide : read apache cache guide

Read more