LiteSpeed has created a built-in cache functionality for it's Enterprise Edition web server. LSCache is included free in 2-CPU+ licenses and as an add-on for other licenses. (Available since version 4.0)

LSCache's features are very similar to those in Apache mod_cache, but implemented in a more efficient way. LiteSpeed cache works like Varnish. It is an output cache for dynamic contents, so the usage is not limited to PHP pages. Unlike Varnish, LiteSpeed cache is built into LiteSpeed's web server, thus eliminating one layer of reverse proxy. This translates into higher efficieny 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.

If there is a LiteSpeed cache plugin available for your web applications (WordPress, WooCommerce, Magento, Xenforo), you should follow the corresponding section to set up your cache. In these cases, following this wiki is not recommended as it was written for more general non-application-specific caching. As a result, it is only applicable when a LiteSpeed cache plugin for your application is not available or you have very customized code base application.

A general way to enable LiteSpeed Cache through rewrite rules is to designate a signature token (such as a cookie) in any page, in most cases it will tell LSWS that cache can be enabled and that the TTL(Time To Live) of the cache freshness will remain acceptable. Generating cookies usually requires application code modification. Please refer to this thread on our forum for examples. It is worth noting that the cache function SHOULD ONLY be used for pages that are supposed to be cached or cache friendly. Abuse use of this feature would result in performance degradation and/or other unexpected behaviors.

Since 4.1.1, private cache support has been added. Private cache is for caching resources for individuals specifically instead of publicly shared resources. The purposes are:

• to maintain a persistent cache for applications that do not have a shared cache.
• to maintain a private persistent cache for specific groups of documents that are not to be shared among other applications.

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:

1. They offer immense benefits to the user of that one client.
2. Almost every client on the visible web (that is, browsers, RSS readers, and other interactive user agents) and a very large number of those on the machine-only parts of the web (that is, spiders and clients of web services) use a private cache of some sort. As such, you can rely upon the presence of at least one cache being involved in almost everything you do on the web.
3. With some representations it may not be appropriate for public caches to cache them or to return those representations without re-validating them but perfectly acceptable for private caches to do so (e.g. anything which can only be seen by authorized users or which changes its representation depending upon who is looking at it). It can even be appropriate for encrypted documents to be so cached (though this requires one to be very sure as to the security of the cache itself, and so is generally not done).

Each particular URL of a website can be set up to be publicly cached, privately cached, or not cached at all, but can not be both public and private cache at the same time. That is to say, you can only setup one cache type for a particular URL. Depending on the situation, you might want to set different URLs to be cached differently. The following outlines a few scenarios helpful in determining which type of caching should be used for a URL or a set of URLs.

• Public cache
  1. Infrequently changed
  2. Popular demand (requested frequently)

• Private cache
  1. Can only be used by one user/client, such as personal information on a web site (for authorized users)
  2. Resources such as documents only available for one particular user or authorized users.
  3. Resources served via the HTTPS protocol
  4. Responses with cookies

• No cache
  1. POST request
  2. Dynamic content (such as time sensitive info)
  3. Frequently changed objects

Although there is an advanced setting "Enable Cache" in the LSWS Web Admin Console on both the server and virtual host levels, “No” or “Not Set” is always recommended since globally-enabled public cache may cause problems when URLs change or other changes happen on the domain. We recommend enabling the cache through rewrite rules. Follow the steps in the following sections to enable LSWS's built-in caching.

For different hosting environments, the steps to set up server level cache root are different. Please choose your hosting environment:

• cPanel/WHM
• Plesk
• Apache Config (No Control Panel)
• LiteSpeed Native

For Advanced Cache Configuration info, look here.

Actually you don't need to change anything here. Just keep the installation default settings. Settings can be enabled through .htaccess file.

LSWS Web Admin Console→Virtual Hosts→mytest→Cache → Cache Policy

Enable Public Cache:Not Set
Check Public Cache: Not Set
Max Object Size: Not Set
Cache Expire Time (seconds): Not Set
Cache Stale Age (seconds): Not Set
Cache Request with Query String: Not Set
Cache Request with Cookie: Not Set
Cache Response with Cookie: Not Set
Ignore Request Cache-Control: Not Set
Ignore Response Cache-Control:Not Set
Enable Private Cache: Not Set
Check Private Cache: Not Set
Private Cache Expire Time (seconds): Not Set

Note:

• Never set “Enable Public Cache” to “yes”. “No” or “Not Set” is always recommended. Even though Cache is disabled globally at the Server Level, it will be enabled through rewrite rules. That's the way it's supposed to be. Cache can be turned on/off with the “CacheEnable” and “CacheDisable” directives in Apache config files: .htaccess (preferred) or httpd.conf, etc.
• Check Public Cache: “Not Set” or “No”. You can enable it through .htacesss by placing the following to enable cache lookup:

<IfModule LiteSpeed>
   CacheLookup public on
</IfModule>

• Cache Request with Cookie can be set to “Yes” as long as the cookie does NOT affect the generated page. Use it carefully.
• Set “Enable Private Cache” to “No”. Setting this to “Yes” turns on private caching. Private Cache is pertinent to each individual user/browser. This is to speed up performance even for logged-in users or cache for individuals instead of the public. “No” is always recommended then you can enable it through .htaccess.

To enable public or private cache, you can use the “CacheEnable” and “CacheDisable” directives in .htaccess and rewrite rules. Rewrite rules may need to be adjusted to your application requirements. “CacheEnable” will enable cache copies to be stored. “CacheLookup” will tell the application whether it should look up the cache or not (No further action or settings are required. CacheLookup will be enabled by default once “CacheEnable” has been set) . “Rewrite rules” will define which is cacheable, which is not.

Cache can be turned on and off by using the “CacheEnable” and “CacheDisable” directives in Apache config files to overwrite cache policies that have been set above that level: .htaccess (preferred) or httpd.conf, etc. Nothing else needs to be done for the cache policy. It will assume the same default settings as the LSWS Server level settings.

• To enable public cache,

<IfModule LiteSpeed> 
CacheEnable public /
</IfModule> 

The above directive will literally enable public cache lookup as well though it is not set in the LSWS Admin configuration nor by “CacheLookup public on” directive. If a LiteSpeed cache plugin for an application is used, “CacheEnable public /” will not be needed. However, “CacheLookup public on” would still be needed. LiteSpeed cache will work through header control. That is, however, beyond of the scope of this wiki.

When using / in your directive, you are enabling public cache on everything located under the website root directory (for example, if your site was located in /home/username/public_html and pointed to http://www.example.com, everything located within that directory and any subdirectories within it would be cached. If you used CacheEnable public /blog, everything under /home/username/public_html/blog, pointing to http://www.example.com/blog would be cached).

• To enable private cache, you can add the following lines to the .htaccess file under the document root of the website,

<IfModule LiteSpeed> 
CacheEnable private /
</IfModule> 

The above directive will literally enable private cache lookup as well though it is not set in the LSWS Admin configuration nor by “CacheLookup private on” directive. If a LiteSpeed cache plugin for an application is used, “CacheEnable private /” will not be needed. However, “CacheLookup private on” would still be needed. LiteSpeed cache will work through header control. This is, however, beyond of the scope of this wiki.

• To disable public cache,

<IfModule LiteSpeed> 
CacheDisable public /
</IfModule> 

• To disable private cache,

<IfModule LiteSpeed> 
CacheDisable private /
</IfModule> 

To enable/disable cache for a certain URL, just replace “/” with desired the URL.

Rewrite rules can be placed in httpd.conf or the in-directory .htaccess file as shown in below.

Note:

• Apache mod_cache directives CacheIgnoreCacheControl and CacheMaxExpire can also be used in Apache config files (httpd.conf or .htaccess) to fine-tune cache policy.
• WHM/cPanel users: since cPanel does not have an option to enable mod_cache, mod_cache directives such as CacheEnable, CacheDisable, etc, need to be manually added to Apache config files: .htaccess or httpd.conf, etc.

Rewrite rules are used to control what content is and isn't cacheable.

Rewrite rule example 1:

RewriteEngine On
RewriteRule (.*\.php)?$ - [L,E=cache-control:max-age=120]

Rewrite rule example 2:

RewriteEngine On
## cache should be available for HEAD or GET requests
RewriteCond %{REQUEST_METHOD} ^HEAD|GET$
## select which pages to cache
RewriteCond %{HTTP_COOKIE} page_contain_cachetoken=yes
# with other condition

RewriteCond %{QUERY_STRING} !s=[a-fA-F0-9]{32}

# excluding certain URLs
RewriteCond %{REQUEST_URI} !/(login|register|usercp|private|profile|cron|image)\.php$

# cache for 2 mins for php pages only
RewriteRule /(.*\.php)?$ – [L,E=Cache-Control:max-age=120]

# for those not met above condition, enable private cache.
RewriteCond %{REQUEST_METHOD} ^HEAD|GET$
## select which pages to serve from private cache
RewriteCond %{HTTP_COOKIE} !page_contain_cachetoken=yes
# with other condition

RewriteCond %{QUERY_STRING} !s=[a-fA-F0-9]{32}

# excluding certain URLs
RewriteCond %{REQUEST_URI} !/(login|register|usercp|private|profile|cron|image)\.php$

# private cache for however long set in cache policy for php pages only
RewriteRule /(.*\.php)?$ – [L,E=Cache-Control:private]

These rules can be placed in one of the 3 locations below:

• .htaccess (last line needs to changed as follows:)

RewriteRule (.*\.php)?$ – [L,E=Cache-Control:max-age=120]
RewriteRule (.*\.php)?$ – [L,E=Cache-Control:private]

• VirutalHost secion in Apache config file
• LiteSpeed native configuration: Web Admin Console → Configurations → Virtual Hosts → Rewrite

Admin Console → Actions → Graceful Restart or run '/path/to/lsws/bin/lswsctrl restart' or 'service lsws restart' from command line.

Since its 4.0.19 release, LiteSpeed Web Server outputs a response header “X-LiteSpeed-Cache: hit” if a request is served from cache.

Since its 4.1.1 release, LiteSpeed Web Server outputs a response header “X-LiteSpeed-Cache: hit,private” if a request is served from private cache.

Note: The LSCache hit rate is calculated based on all files served. Many of the files served by LSWS, like CSS or HTML, are intentionally not cached by LSCache. Because these files are included in the LSCache hit rate calculation, the hit rate may sometimes look much lower than one might expect.

Set up a cron job to purge outdated cache files on disk and add the following entry in /etc/crontab

• /10 * * * * root find /tmp/diskcache -type f -mmin +8 -delete 2>/dev/null

Note: The cron job shown above deletes cached files that are more than 8 minutes old every 10 minutes. Since the cache TTL is set to 120 seconds (2 minutes) it's safe to delete these files as they are way past the TTL.

.htaccess Rewrite Rule Examples:

If you are running a WordPress/WooCommerce/Magento/Xenforo site, you should NOT follow this wiki. Instead, your plugins should be installed and configured by following the related wikis.

If you are running Joomla site, see examples here.

If you are running vBulletin site, see examples here.

If you are running Mediawiki site, see examples here.

If you are running IP Board site, see examples here.

If you are running vBSEO site, see examples here.

If none of above used, please refer the following general rewrite examples.

  RewriteEngine On
  RewriteRule cacheablefolder/(.*\.php)?$ - [L,E=cache-control:max-age=120]

Note: Only cache *.php files in “cacheablefolder” directory. As pointed out previously, it is a good practice to cache only the files that are supposed to be cached.

Note: %{ORG_REQ_URI} is a LiteSpeed specific variable. In this case, it keeps the value of %{REQUEST_URI} prior to the rewrite to index.php in the first part

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/index.php
RewriteCond %{REQUEST_URI} (/|\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$  [NC]
RewriteRule (.*) index.php 

# this part is for public cache.
RewriteCond %{REQUEST_METHOD} ^HEAD|GET$
RewriteCond %{HTTP_COOKIE} !loginuser
RewriteCond %{ORG_REQ_URI} !^/index.php$
RewriteCond %{ORG_REQ_URI} !^/administrator/
RewriteCond %{ORG_REQ_URI} (\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$  [NC]
RewriteRule .* - [E=Cache-Control:max-age=300,L]

Note: This example demonstrates how LSCache rewrite rules fit in an application's rewrite rules. The first part is from the application (such as Joomla). Essentially everything goes through index.php (Joomla framework) to process.

Second part of the ruleset indicates that LSWS only caches requests if they

• Are HEAD or GET type requests AND
• Don't contain loginuser in the HTTP_COOKIE AND
• %{ORG_REQ_URI} is not /index.php AND
• %{ORG_REQ_URI} does not start with /administrator/ AND
• %{ORG_REQ_URI} ends with .php or .html or .htm or etc.
• The TTL of the cache is 300 seconds (5 minutes).

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/index.php
RewriteCond %{REQUEST_URI} (/|\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$  [NC]
RewriteRule (.*) index.php 

# this part is for private cache, note that HTTP_COOKIE is for loginuser
RewriteCond %{REQUEST_METHOD} ^HEAD|GET$
RewriteCond %{HTTP_COOKIE} loginuser
RewriteCond %{ORG_REQ_URI} !^/index.php$
# there is no need to exclude admin area. it can be private cached.
# RewriteCond %{ORG_REQ_URI} !^/administrator/
RewriteCond %{ORG_REQ_URI} (\.php|\.html|\.htm|\.feed|\.pdf|\.raw|/[^.]*)$  [NC]
RewriteRule .* - [E=Cache-Control:private,L]

The ruleset indicates that LSWS only privately caches requests if they

• Are HEAD and GET type requests AND
• DO contain loginuser in the HTTP_COOKIE AND
• %{ORG_REQ_URI} is not /index.php AND
• %{ORG_REQ_URI} ends with .php or .html or .htm or etc.
• The TTL of the cache is however long set in the cache policy for private cache.

While it is not recommended to have private caching enabled (in the cache policy), doing so enables private caching for all domains/vhosts. However, certain domains/vhosts may not work well when private cache is on by default. In this case, we need to disable private caching for those domains/vhosts.

To do so,

1. Purge the private cache copy if it is still valid(fresh).
2. Put the following entry in .htaccess under document root of the domain/virtual host in question.

RewriteEngine On
RewriteRule .* - [E=Cache-Control:no-cache] 

or put the following in the vhost section of your httpd.conf

CacheDisable private