LiteSpeed

Tag: lsws v6.0

  • LiteSpeed Web Server v6.0

    LiteSpeed Web Server v6.0

    LiteSpeed Web Server v6.0 Now Available
    LiteSpeed Web Server v6.0 is now available! This important update provides significant gains in performance, security, and Apache compatibility, so let’s take a look!

    What’s New in 6.0?

    In v6.0, we tackled cache engine enhancements, Asynchronous ModSecurity, support for the new HTTP/3 v1, improved Apache compatibility, and so much more.

    Cache Engine Enhancements

    This update introduces a few enhancements to the LSCache Engine, including POST response caching, and improved PURGE/REFRESH by URL. We designed these enhancements to provide greater flexibility in managing your customized web application caches.

    We go into a lot more detail in this blog post.

    Asynchronous ModSecurity Engine

    As of LiteSpeed Web Server v6.0, we have introduced a separate worker thread pool for ModSecurity processing. Now, when a request needs to be scanned, LSWS offloads it to the dedicated thread pool. There are numerous benefits to this. For example, not only does it improve performance, but it also adds one important feature: the ability to scan the response body without clogging the main event loop thread. We describe these benefits and others in more detail in this blog post.

    HTTP/3 v1 Support

    At long last, HTTP/3 is on the verge of becoming official. We have supported HTTP/3 and QUIC at every milestone along the way, and so we are ready to support v1 of the new protocol.

    Apache Compatibility Improvements

    ProxyPass

    ProxyPass is a feature frequently used to facilitate cPanel’s Live Transfer feature. Live Transfer requires a domain name in the target URL, but until now, LiteSpeed Web Server could not meet this requirement. Previous versions required a manual external application configuration in order to work around a target URL with domain name, but this is no longer the case.

    LSWS v6.0 supports external application configuration using a domain name for the target address. Now you can use Live Transfer to migrate LiteSpeed sites between servers with near zero downtime.

    Version 6.0 has better support for websocket backends, too. Now secure wss:// connections are supported..

    Conditional Configuration

    One big change to Apache 2.4’s configuration is the addition of the <if><else> context to enable configurations based on the runtime evaluation of an expression.

    For LiteSpeed to support this new configuration directive, we needed to make big changes. This is because LiteSpeed merges all of the various levels of configuration together one time, when a configuration is saved, in order to improve runtime performance. This method does not lend itself to runtime changes.

    So, LSWS v6.0 includes the necessary changes to support conditional configuration.

    Bubblewrap Support

    Bubblewrap is a lightweight sandbox application by Flatpak, which implements Linux namespaces. Supporting Bubblewrap essentially gives LiteSpeed Web Server a full sandbox, including operating-system-supported isolated mounts, user/group IDs, interprocess communications, users, cgroups, host names and more.

    Learn more about Bubblewrap and LiteSpeed in this blog post.

    Cgroup resource throttling

    In order to maintain compatibility with DirectAdmin’s new per-user resource throttling feature, LiteSpeed has added simple cgroup-based resource throttling through lscgid. Now, not only is it possible to control PHP processes, but you may throttle CGI scripts as well.

    Conclusion

    In conclusion, we encourage you to update to LiteSpeed Enterprise v6.0 today! It is available immediately, and you can get a full list of updates on our website. Still trying to make up your mind about LiteSpeed Web Server? Why not give our 15-day Trial License a try?

  • Cache Engine Enhancements

    Cache Engine Enhancements


    LiteSpeed Web Server v6.0 is here! Among other cutting edge features, this update introduces a few enhancements to the LSCache Engine. These changes, including POST response caching, and improved PURGE/REFRESH by URL, were designed to provide greater flexibility in managing your customized web application caches.

    POST Response Caching

    Previously, only GET responses were cacheable, but as of LSWS v6.0, you will be able to cache POST responses as well.

    To take advantage of this feature, two things need to happen:

    1. POST caching must be enabled at the server level: In the WebAdmin Console, navigate to Cache Policy Configuration and set Enable POST Cache to Yes.
    2. The response header must include X-LiteSpeed-Cache-Control, which is used to indicate that the response is cacheable.

    Cache Tags via Rewrite Rules

    Cache tags are the mechanism used by LiteSpeed’s cache engine to group content together and enable intelligent purging of related cache objects. Traditionally, tags have been assigned via the X-LiteSpeed-Tag response header, but v6.0 will allow you to do it with rewrite rules.

    Rewrite rules can set cache tags for any cached response that hasn’t already been tagged, like so:

    RewriteRule /cached/url - [E=Cache-Tag:exampletag]

    If tags have already been assigned by response header, the rewrite rule will be ignored.

    To assign multiple tags to the cached response, the tags must be within quotes:

    RewriteRule /cached/url - [E=”Cache-Tag:tag1,tag2”]

    Enhanced Purge/Refresh by URL

    LSCache’s earlier purge-by-URL feature only purged a single matching cache object. If there were varying copies of the URL, like in the case of mobile and desktop views, only one of those copies would be purged.

    In v6.0, the request URL will be treated as a special cache tag. It will always purge all varying copies of the same URL, and may also be used to purge cache objects for the same URL with different query strings.

    The methods for purging by URL will not change. You may continue to use the PURGE or REFRESH request methods, or the X-LiteSpeed-Purge response header. Additionally, the lsws/admin/misc/purge_cache_by_url script is still available to send a PURGE/REFRESH request, but the client IP must be trusted.

    Examples Using the X-LiteSpeed-Purge Response Header

    Purge /url/to/be/purged, including varying copies if any exist:

    X-LiteSpeed-Purge: /url/to/be/purged

    Purge /url/to/be/purged, including any copies with query strings (regardless of what that string may be):

    X-LiteSpeed-Purge: /url/to/be/purged?*

    This won’t work with wildcards or Regex patterns. The only acceptable use of * when purging by URL, is to signify “any query string” as in the example above. In other words, do not use /url/prefix* to purge all URLs starting with /url/prefix. If you must purge a group of URLs in this manner, you should use an explicit cache tag. In other words, assign all relevant URLs starting with /url/prefix a particular tag, and PURGE/REFRESH that tag.

    Stale purge /url/to/be/purged, including any copies with query strings:

    X-LiteSpeed-Purge: stale, /url/to/be/purged?*

    Stale purge is equivalent to a REFRESH request type. It enables an out-of-date cache object to be served to users while a fresh copy of the page is in the process of being cached. This is useful on busy sites, where there could be hundreds of requests for a page before the caching process has completed. In these cases, it may be better to serve out-of-date content from cache than to attempt to fill such a volume of requests with uncached content.

    Conclusion

    With POST response caching, the ability to add rewrite-rule-based cache tags, and improvements to purge-by-URL, LSCache is upping its game yet again. A tradition of excellence in web app acceleration continues!

    Get a trial license and try LiteSpeed Web Server v6.0 today!

  • Asynchronous ModSecurity Enhancement

    Asynchronous ModSecurity Enhancement

    Asynchronous ModSecurity Engine
    LiteSpeed Web Server’s proprietary ModSecurity engine already delivers stellar performance. We’ve achieved that with an implementation that is highly optimized and well-integrated into the server. In-depth testing shows that LiteSpeed’s ModSecurity solution is faster and more efficient than Apache’s or nginx’s.

    Even so, ModSecurity, being CPU intensive, can be a drag on performance. Our implementation already reduces the CPU impact with measures such as:

    • Intelligently skipping some rules based on the request input
    • Caching regex results to speed up regular expression matching
    • Execution suspension for long-running rule processing

    That said, we’re not ones to rest on our laurels! And that is why we are pleased to announce a major feature enhancement for LiteSpeed Web Server v6.0: an Asynchronous ModSecurity Engine.

    The Problems with ModSecurity

    Implementing ModSecurity is a challenge due to the heavy reliance on CPU, limited resources available, and ModSecurity’s tendency to clog the main event loop thread.

    Clogging the Main Event Loop Thread

    Popular ModSecurity rulesets contain hundreds of rules. Depending on the input size, one request could take upwards of a few hundred milliseconds to scan. In an event-driven server, where the main event loop thread handles all events, everything else must wait while a ModSecurity scan executes.

    LiteSpeed already has a mechanism in place that tracks the time spent in the ModSecurity engine, and suspends execution if necessary, to give other events a chance to process in a timely manner. But even with this execution suspension, the main event loop can still get bogged down by ModSecurity. For example, regular expression execution cannot be interrupted, and some of these executions (particularly during ReDoS attacks) can be highly expensive.

    Limited CPU Resources Available

    The main event loop thread uses a single CPU core. When executing ModSecurity rules in the main event loop thread, the only way to get better performance is to increase the number of worker processes, which means upgrading to a more powerful license.

    Solving ModSecurity’s Problems

    One obvious solution to the problem of CPU resources is to create more lshttpd workers. The more workers available, the more CPU processing power ModSecurity can take advantage of. But managing a large number of workers means a more expensive license. Until now.

    LiteSpeed is introducing a better way.

    As of LiteSpeed Web Server v6.0, we have introduced a separate worker thread pool for ModSecurity processing. When a request needs to be scanned, it is offloaded to the dedicated thread pool. The benefits of this are numerous:

    • Most importantly, it allows the main event loop thread to become available immediately for processing the next event.
    • CPUs with a large number of cores can be better utilized without having to upgrade to a more powerful license.
    • The worker thread pool may have a different priority and CPU affinity from the main event loop thread, which minimizes the potential impact of thread scheduling.
    • With a dedicated worker thread, LiteSpeed’s ModSecurity engine is able to scan the response body. Support for applying ModSecurity to a response body was not available until now, mainly due to the problems described above.

    LiteSpeed Web Server v6.0 is available now. Download it and try it out today!