What is LiteSpeed Cache ?
LiteSpeed Cache (LSCache) is a built-in, high-performance dynamic content acceleration feature of the LiteSpeed Web Server.
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, Xenforo, Mediawiki, Joomla, Drupal, Magento, Prestashop etc ), you should follow the corresponding section to set up your cache. LiteSpeed cache plugin for Magento1/Magento2(LiteMage 1/LiteMage 2) and litespeed cache plugin for prestashop will need LiteSpeed Enterprise to work and can not work with OpenLiteSpeed. 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 OLS 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.
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 web pages 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.
Advantages of Private Cache
- They offer immense benefits to the user of that one client.
- 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.
- With some web pages it may not be appropriate for public caches to cache them or to return those web pages 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).
When to use Public Cache, Private Cache, or no Cache
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.
- Infrequently changed
- Popular demand (requested frequently)
- Can only be used by one user/client, such as personal information on a web site (for authorized users)
- Resources such as documents only available for one particular user or authorized users.
- Resources served via the HTTPS protocol
- Responses with cookies
- POST request
- Dynamic content (such as time sensitive info)
- Frequently changed objects
How to enable LSCache?
To enable LSCache on openlitespeed, you will need to register/add/configure LSCache module first(latest OLS has cache module built-in hence there is no seperate cache module required). Then depending on your application, you will need to install a corresponding litespeed cache plugin for that application if the corresponding plugin is available. However, some LiteSpeed cache plugins ( such as Prestashop and LiteMage for Magento) are for LiteSpeed Enterprise only and don’t work with OLS at all. If the litespeed cache plugin for that application is not available, you may try to use rewrite rules to enable cache for your application. Your application may not be cache-friendly such as Ads site, eCommerce site etc.