OpenLiteSpeed
OpenLiteSpeed is a relatively newer webserver, proving to be slowly becoming a more popular alternative to Apache & Nginx on Linux. One (or two) of the prime selling points are the inclusion of a Web GUI Console to make changes to and 'Gracefully' Restart the webserver (including remotely), and also inclusion of the LSCache, which provides the ability to cache PHP Pages, both in a public or private cache depending on the type of page being displayed.
At the time of writing, this page will be less about how to install the server itself (DigitalOcean has some great write-ups on that with installing a 'LOMP' Stack if you were looking for a step-by-step guide), but more about the differences and random setup bits you may encounter whilst installing and setting up your server specifically for Moodle.
Initial Setup
During the initial setup, it's actually relatively straightforward and walks you through most of it. One thing that may be new for some people is the concept of 'Listeners' and 'Virtual Hosts'. Virtual Hosts does what it says on the tin, and allows you to have a server responding to multiple domains. Configuration is independent in each host, but for common settings, these can be configured at Server Level and will then be inherited by each host. Settings applied at the host level however override server-wide settings.
Listeners
The Listeners are basically what listens for HTTP and HTTPS traffic, and on what port it will listen. Unfortunately you can't bind to multiple ports like other software, so you'll typically need to create two listeners for HTTP and HTTPS on Ports 80 and 443 respectively. Fortunately later versions of Moodle (e.g. 4.2) seem to automatically redirect to whatever is set in 'CFG -> wwwroot', so if this value is set to https://, then your Moodle Site will automatically redirect to HTTPS anyway, saving you a step - yay!
Virtual Hosts
One small thing to note during the Virtual Host(s) setup is that it will prompt you for a "Virtual Host Root" - this is not the document root, but is instead where the configuration files for your Virtual Host are stored. The default location for the Virtual Host root is typically okay, you will however need to manually setup the Document Root (interestingly it doesn't actually prompt you for this). This can be found under the Virtual Host -> General -> Document Root.
Also at the time of writing (July 2023), it doesn't specify where the Server Root is either, just the options for setting it. By default, this is located at /usr/local/lsws on Linux, and will come in handy to remember this location for later as well, especially in regards to sub-locations.
Running PHP Scripts
To have PHP Scripts run, you'll need to change the "Enable Scripts" option under the particular Virtual Host you've created, specifically found under Basic -> Security -> Enable Scripts in the Web GUI.
SSL Certificates & HTTPS
SSL Certificates can still be made and updated automatically through Certbot, OpenLiteSpeed has a document (Quick install SSL with Let's Encrypt) that covers the how-to's on this pretty nicely.
PHP Optimization & Caching
Now for the fun stuff - post setup how to make it go faster, without adding horsepower (aka the efficient way) :D
PHP Optimization
PHP Optimization (including OpCache Setup) is largely the same as any other webserver, and is still done through the php.ini file primarily. All the stuff in Performance Recommendations largely applies, especially with PHP settings. The difference however, is the location of the php.ini file - by default this is found at /usr/local/lsws/lsphpX.X/etc/php/X.X/litespeed/php.ini (X.X being the version of php you've installed).
This is due to the way LS handles PHP and PHP versions - it actually installs (or more accurately you install) a different php package for use with the webserver, titled lsphpX.X as opposed to the regular phpX.X you'll find under APT. It also calls PHP slightly differently in terms of child processes etc., but I'm blurry on the details - more information can be found in the LSS docs. This also does cause some complications with cron depending on how you invoke it, which I'll cover towards the end.
There's also a document OpenLiteSpeed has written up about Server Level Optimization for both Shared Hosting and Dedicated Hosting, which can again be found in the docs.
HTTP3/QUIC
HTTP3/QUIC is a new protocol that is designed to essentially serve webpages quicker, by doing some fancy stuff in the background that I haven't really read up on, so I won't pretend to know what I'm talking about here. It is one of the few webservers to support this at the time of writing though, so is pretty neat. Enabling it is also super simple - just open Port 443 for UDP traffic on your webserver, and LS will detect the change and enable HTTP3/QUIC automagically. It can also be confirmed through a website they host to confirm it, conveniently called "HTTP/3 Check".
LSCache
Finally the bit that makes potentially the biggest difference - the LiteSpeed Cache. This can become quite a long discussion, so I'd suggest pre-reading up on the docs about what it is, and how it works - fortunately they're not too long and are pretty succinct on explaining the basics of caching, and why you need a Public vs Private Cache as well. Assuming all of that is known/understood, we'll continue below:
So Moodle naturally on all pages bar the login page does contain specific using data (e.g. name and what is displayed, such as courses), meaning that is isn't suitable for Public Caching. In fact I tried it just to see what would happen, and you have strange issues such as other user's names being displayed, and the page being cached for them. The test student I used only had limited course access, so when I went to login, all I could see were their courses and nothing else - including the Site Administration tab! Not exactly ideal for a Site Administrator, so long story short I'd recommend not enabling the Public Cache if you're looking to keep it simple.
This leaves the Private Cache - enabling this does work well and does improve performance (again, there's a site to check if this is enabled/functioning, called "LSCache Check". So apt, I like that sort of naming). Considerations are however the size and userbase of your Moodle Setup - on our setup, we're quite small so caching really doesn't have much in the way of disk space/memory usage but provides a big benefit. Naturally though, as you scale and have to say store a copy of each of the pages for ~1000 users this can become a problem. So see how this applies to you and process from there.
As to how to actually enable the cache, funnily enough the LS Docs for that are out of date, and the "how-to" has changed - at the time of writing, from the Web GUI, go to Server Configuration -> Modules, and under there you'll find cache preloaded. There are a few options in here (again covered in the docs), but the main ones for controlling/enabling caching are checkPrivateCache, checkPublicCache, enableCache and enablePrivateCache. Set these to 1 or 0 as appropriate for your installation, 1 being enabled and 0 being disabled.
You've also got the option of configuring what is cached through Rewrite Rules - there's documentation and some small examples on this, but I'm unfortunately not familiar enough with the elements in Moodle's .php files to be able to write some caching rules up. This however would naturally mean that you could potentially create some rules where everything is cached optimally (public data in the public cache, private data in the private cache), so I think definitely has some benefit in the future, especially if someone does work it out. If you do, please post it in the forums, and we can add it here!
X-Sendfile
LSWS does support X-Sendfile, though they refer to it as "Internal Redirect" in their documentation, and the actual header is "X-LiteSpeed-Location". Unfortunately I couldn't get this working on our site - I'm thinking it has something to do with the redirects being URI's instead of paths, but couldn't quite work it out. If you do happen to figure it out/fix it, please mention something in the forums and we'll get it added here!
Potential Cron Issues
This is a bit of a strange one, and could occur depending on the packages you have installed on your system. If you have installed the lsphpX.X versions of the packages, then you'll need to point Cron to use these packages which should in theory work (I haven't tested this method, instead opting for the other option). Otherwise, you'll need to install the regular php packages with the required dependencies (phpX.X, phpX.X-common, phpX.X-mbstring, phpX.X-intl, phpX.X-curl) and have Cron using that version of PHP. Without all the additional packages listed Cron won't function properly, as it will be missing dependencies. An easy check to confirm operation is to try run tasks manually through both the Scheduled Tasks Queue, or the Ad-Hoc Tasks Queue as well, and watch the output - it'll let you know if something is missing.
Success!
If you've made it this far, then in theory you should have a functioning server that hopefully should be running pretty well. On our setup, we found that performance was noticeably quicker overall (again because of caching primarily, when it had a miss page load times were significantly longer), and that our Moodle Benchmark scores had improved as well - going down from 173 Points (aka 1.730s to complete all its tasks), down to 31 Points (0.310s to complete all its tasks, so not insignificant). MariaDB was a factor in this as well, but clearly performance has improved across the board using more modern software/packages.
One question that may remain is whether this is the right fit for your installation - OpenLiteSpeed has documentation and comparisons against Apache & Nginx as to what it will and won't do, and DigitalOcean also has a comparison between Apache & Nginx (Apache vs Nginx: Practical Considerations), which talks more about those two server options in particular, but may give you further background as to what may suit your needs best.
