Notes: LiteSpeed Certification Part 1

I have so much to catch up on in terms of blogging and reminiscing over the last few months here and I’m promising myself that I’ll get to it soon enough. In the meantime, I wanted to jump to present day and talk about a Professional Development meeting that I joined today with some of the team around Reclaim Cloud.

@JimGroom‘s cool virtual setup

Reclaim Cloud still feels a bit intimidating for me, so I’ll take any extra help or training that I can get. One thing that was recommended during the call was to become more familiar with LiteSpeed as a whole, given its a backbone for most of our infrastructure on Reclaim Cloud. A cPanel LiteSpeed Certification was mentioned, and now here we are. I’ll be using this post (and potentially others) to take notes as I make my way through the course. Feel free to follow along, or don’t, but I want to have these notes documented somewhere that I can link back to later on.

Supporting and Understanding LiteSpeed

LiteSpeed Web Server (LSWS) is a drop-in replacement for Apache. Which makes sense– we have Apache running on the majority of our servers at DigitalOcean. (If you want my breakdown of Apache, I wrote about it here & here.)

  • LS handles thousands of concurrent connections while keeping a small memory footprint
  • secure, high-performance
  • compatible with Apache features like mod_rewrite, .htaccess, and mod_security; can load Apache files;
  • integrates cleanly with cPanel, CloudLinux

Other LSWS Features:

Differences between Apache and LiteSpeed

Installing LiteSpeed Web Server

LSWS can be installed on Linux-based systems using command line & requires about 200MB disk space. (Quick Install guide.) Installing as root sets the default directory to /usr/local/lsws. Running the manual installer is usually sufficient, but the process can be automated for bulk provisioning. Based on what I know about our infrastructure team and their server setup scripts, they likely have the LSWS installation automated by adding a lsws.options file in the same folder as the installer.

The LSWS interface in WHM will be installed as well, and allows you to:

  • switch back and forth between Apache and LSWS (helpful for testing or observing behavior differences)
  • run apache and LSWS parallel to each other by updating the LSWS port offset

To take advantage of LSWS caching abilities, you have to configure a cache root. From there you can do things like integrate caching abilities with existing WordPress installations. LiteSpeed can recognize WP applications on the server and automatically install a LS plugin in each application, or you can Mass enable/disable caching at the server level.

LSCache

  • resembles the mod_cache module commonly used in Apache
  • not limited to PHP pages or dynamic content
  • uses rewrite rules to improve flexibility
  • caching components are built directly into LSWS
  • handles compressed and uncompressed requests
  • stores files on disk
  • caches based on LSWS-specific response headers or rewrite rules

Plugins Offered

LSWS caching plugins can be found here.

Optimizing LiteSpeed Environments

  • speed up cache by moving it to RAM, RAMdisk, or SSD (steps here)
  • by default cache is stored in /home/lscache or /home/$USER/lscache
  • you can disable/enable cache on a per account basis

Troubleshooting Common LSWS Issues

For example, cache is enabled but site is still slow (i.e. a “Cache Miss“). Quick fix is gracefully restarting LiteSpeed. This can be done through WHM interface:

Or by using the following command:

/usr/local/lsws/bin/lswsctrl restart

By gracefully restarting, LiteSpeed is able to regenerate the LSCache folder with appropriate permissions.

LSPHP 5.3

In the latest release of LSPHP 5.3, here are some changes of note:

  • LSPHP 5.3 configures PHP handler automatically– ea-php and alt-php handlers work together
  • existing PHP handler configurations will be honored whenever possible
  • PHP won’t die when LiteSpeed restarts (called PHP detached mode)
  • PHP CRIU is enabled by default, and only works with CloudLinux. I don’t really know what PHP CRIU is honestly, but after a quick search, it looks like a Linux software that can freeze containers and applications for restoration, debugging, migrations, etc. Update: LSWS docs suggest that PHP CRIU support has been disabled.

Optimizing LSPHP Configuration & suEXEC

suEXEC is an execution method that makes PHP more secure by running each PHP process as the owner of a particular account. Meaning, if a user on the a server is compromised, PHP scrips that are executed from their account will not have access to data in other accounts. suEXEC is industry standard at this point, and the LSPHP modes available are:

  • suEXEC Worker– creates new PHP processes only as needed, kills them when finished; resource efficient, but incompatible with caching. Because of this, you should only user Worker mode when you need custom php.ini files for something like Cloudlinux, of if resources are too limited for ProcessGroup.
  • suEXEC Daemon– improves performance by forking new PHP processes from a constantly running parent process; effective caching; no custom php.ini files (i.e. not compatible with CloudLinux)
  • suEXEC ProcessGroup– default mode; provisions parent processes which easily spawn child processes; reduced overhead, faster process handling; allows for custom php.ini files, per-user caches; additional memory requirements due to high process volume and large caching

Ok– I’m about halfway through the course so I’ll press pause for now and pick this up later in the week. :)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back to Top