General Guideline to use LiteSpeed Cache
LiteSpeed has made a built-in cache functionality (an advanced feature for Enterprise 2+CPU license) available since version 4.0 (March, 2009), and keeps improving throughout the later 4.0.x releases and 4.1RC releases. As of 4.1.1 (May, 2011), private cache support is added.
LiteSpeed cache has similar features as Apache mod_cache but implemented in a more efficient way, and works like Varnish. It is an output cache for dynamic contents, so the usage does not limit to PHP pages. Unlike Varnish, it is built into LiteSpeed web server, eliminating one layer of reverse proxy. Hence more efficient for static contents. The uniqueness of LiteSpeed cache is that it uses rewrite rules (either in configuration files or .htaccess) to control its behavior for maximum flexibility.
A general way to enable LiteSpeed Cache through rewrite rules is to designate a signature token (such as cookie) in a page (or any page) in most cases to tell LSWS that cache can be enabled and TTL(Time To Live) of the cache freshness however acceptable. Generating cookie usually requires application code modification. Refer to http://www.litespeedtech.com/support...ead.php?t=4679 for example. It is worth noting that the cache function SHOULD ONLY be used for the pages that are supposed to be cached or cache friendly. Abuse use of this feature would result in performance degradation and/or other unexpectancies.
Since 4.1.1 (May, 2011), private cache support is added. Private cache is for caching resources for individual specifically instead of public shared. The purposes are:
Here are the steps to enable LSWS built-in cache:
1. Enable cache function at Server level in LSWS
LSWS Web Admin Console->Virtual Hosts->mytest->Cache -> Cache Policy3. For imported Apache vhost:
Cache can be turned on/off with "CacheEnable" , "CacheDisable" directives in Apache config file. Nothing needs to be done for the cache policy. It will assume the same default settings at LSWS Server level. Rewrite rules can be placed in httpd.conf or in-directory .htaccess file as shown in step 5 below.4. For native LSWS vhost:
Setup Cache Policy (LSWS Web Admin Console->Virtual Hosts->mytest->Cache -> Cache Policy)5. Create/Add rewrite rules for caching %
6. Restart LSWS to make changes effective.
Admin Console -> Actions -> Graceful Restart or issue '/path/to/lsws/bin/lswsctrl restart' from command line.7. Verify if pages are served from LSWS cache
Since 4.0.19 release, LiteSpeed outputs a response header “X-LiteSpeed-Cache: hit” if a request is served from cache.
Since 4.1.1 release, LiteSpeed outputs a response header “X-LiteSpeed-Cache: hit,private” if a request is served from private cache.8. Cache clean up (Optional)
Setup a cronjob to purge outdated cache file on disk and add the following entry in /etc/crontab
Rewrite Rule Examples:
Public Cache vs. Private Cache
A public, or "shared" cache is used by more than one client. As such it gives a greater performance gain and a much greater scalability gain, as a user may receive cached copies of representations without ever having obtained a copy directly from the origin server. Reverse Proxies (gateway caches) and the vast majority of proxies are public caches.
A private cache is only used by one client. Generally this applies only to a cache maintained by that client itself, though if you had a proxy that was only being used by one client (say you had a small LAN for your own use only and put a web proxy near the gateway) it would be possible to configure it to act as a private cache. Private caches do not offer quite as much scalability as public caches, but they do have certain important advantages over public caches:
When to use public cache, private cache, or not to cache
- Can be shared by many users such as site logo, navigation images, js, css, etc.
- Change infrequently
- Popular demand (requested frequently)
- Can only be used by one user/client such as personal information on web site (for authorized user)
- Resource such as documents only available for one particular user or authorized user.
- Resource served via HTTPS protocol
- Response with cookie
- POST request
- Dynamic content (such as time sensitive info)
- Frequent changed objects
This guideline is moved to wiki which will reflect future changes and updates.
Generally this applies only to a cache maintained by that client itself, though if you had a proxy that was only being used by one client (say you had a small LAN for your own use only and put a web proxy near the gateway) it would be possible to configure it to act as a private cache.
|All times are GMT -7. The time now is 03:08 PM.|