The Litespeed Web Server.

The Litespeed web server. In this post I’ll be talking about what the Litespeed web server is, what it does, how it works, and why you might want to use Litespeed web server based hosting.

There is a lot of documentation covering the Litespeed Web Server, but this is a bit much for non-system administrators, and the purpose of this post is to tell you about Litespeed itself, rather than how to administer it.

If you don’t run your own server, you’re reliant on your hosting provider to make this available to you. This is because Litespeed is part of the underlying stack, rather than being something you can deploy in your hosting.

I guess I’d better provide a bit of information about what the underlying stack is.

The Underlying Stack.

When you’re operating some kind of web application (be that a site made using WordPress, or a Customer Realtionship Management (CRM) system used by a sales force, or even Facebook) you need more than just the web application itself for it to run.

Most web applications consist of PHP code, which is basically the “computer program” aspect of the web appllication, and a database. The database is usually used to store variable information (things humans have defined or saved in their web application).

In the context of WordPress, variable information consists of things like the address of your website, the content of pages, your login username and password, and the customisation you undertake on your theme. All of this is stored in the database.

In the context of a Customer Realtionship Management (CRM) system, if you enter a potential customer’s details in to the CRM it’s saved in the database. If a lead is entered in to the CRM with a potential value associated with it, this is also saved in the database. The potential values associated with leads can then be obtained from the database by the web application to do things like make graphs or provide a “total value of leads combined” type figure.

So let’s just recap on a few things that I’ve mentioned above:

Web application
PHP
Database

For these to be used, respective services need to be running on the underlying server:

Web application (needs a web server to serve the application to visitors or users)
PHP (needs PHP to be installed on the server for PHP code to run)
Database (a database sever is needed to operate and use databases)

The web server, the database server and PHP all make up parts of the underlying stack, and they themselves need something to run on, namely an operating system.

One of the most common stacks that you may have heard of is the LAMP stack, this is:

Linux (the operating system that allows the additional following services to be operated)
Apache (the web server)
MySQL (the database server)
PHP (a binary – the PHP interpreter – and, in most cases, a service or module that integrates with your web server to process PHP scripts.)

If you’re running a WordPress site, it’s most likely going to be running on a stack of this nature (or at least similar to it).

If you’re using a shared hosting account with a hosting provider, you don’t have access to this stack. You can make use of it, but you can’t do things like stop and start any services, or change the configuration of the stack.

The reason that I’m telling you about the stack in this post about Litespeed, is because Litespeed is a replacement for one of the components in this stack, and that’s Apache, the web server.

So if you’re running a site on a platform using the stack above, your site runs on the LAMP stack.

If your hosting provider Switches from Apache to Litespeed, then I guess you’d b running your site on the LLMP stack.

The key point here is really that you don’t have much choice in the stack, or the ability to make the switch from Apache to Litespeed, if you’re using shared hosting.

The other thing to bear in mind is that Litespeed isn’t specific to the web application you’re running.

Although most of the content on my blog is about WordPress, the Litespeed web server isn’t WordPress specific, as it’s something that runs in the underlying stack (rather than in WordPress itself).

Although there is a WordPress plugin that’s specifically designed to work with the Litsepeed web server this is used to interface with the Litespeed web server, rather than being an actual Litespeed web server in it’s own right. This plugin alone is blog post in itself, which I’ll be writing in the near future.

Now we’ve got an idea of how things fit together as part of the server, stack and web application, let’s talk about what Litespeed actually is.

What the Litespeed Web Server Is.

As the name suggests the Litespeed Web Server is indeed a web server. It’s job is to serve websites (and / or web applications as I’ve mentioned above). The Litespeed web server can be used as a drop in replacement for Apache. Also as the name suggests the Litespeed Web Server is speedy, or at least designed to be.

Drop In Replacement For Apache.

What this means is that the Litespeed Web Server can easily replace Apache, as it adheres to the same configuration files that Apache uses, and it works in a similar manner. This means that it can directly replace Apache without requiring changes to the existing setup. This makes it easy for administrators to switch to LiteSpeed without a steep learning curve.

Although it required a bit of planning, and care, it is possible to switch from Apache to Litespeed in a live production environment.

Litespeed Web Server Is Speedy.

One of the main advantages of Litespeed Web Server is its performance. It is known for being faster and more efficient than Apache, especially when serving dynamic content. It acheives this through various optimization techniques, including event-driven architecture and a highly efficient LSAPI (LiteSpeed Server Application Programming Interface).

How the Litespeed Web Server Improves Performance.

The main motiviation to switch to the Litespeed Web Server is to gain the benefit of it’s improved performance.

The improvement in performance is likely to result in reduced page load times in the context of site visitors.

The improvement in performance is also something that’s seen at server level as well, as the Litespeed Web Server can do things like handle a greater amount of concurrent requests. From a server perspective this means lower resource usage (such as RAM and CPU).

To go in to a bit more depth on the speed/performance side of things:

Faster Performance: The Litespeed Web Server is engineered with performance in mind. It uses an event-driven architecture, which allows it to handle a large number of simultaneous connections efficiently. This can lead to faster response times for web requests. When serving static content or executing dynamic scripts, LiteSpeed often performs these tasks more quickly than Apache.
Efficiency in Dynamic Content Handling: Dynamic content refers to web pages or scripts that are generated on the fly (by code executing and interacting with a database, which is how most web applications including WordPress work), usually in response to user requests. Examples include PHP scripts, database-driven content, and other server-side processing. LiteSpeed is designed to handle dynamic content efficiently, thanks to features like LiteSpeed SAPI (Server Application Programming Interface) and other optimizations. This efficiency is particularly noticeable in environments where a significant portion of the content is generated dynamically.
Lower Resource Usage: The Litespeed Web Server is known for its lower resource footprint compared to Apache, meaning it can serve the same amount of traffic using fewer server resources (CPU and memory). This efficiency is especially important in high-traffic scenarios or environments where resources are constrained. Effectively, it can do more, using less server side resources when doing so.
Event-Driven Architecture: The Litespeed Web Server uses an event-driven model, as opposed to the process-based or threaded models used by Apache. This architecture allows LiteSpeed to handle many connections simultaneously with less overhead, contributing to its performance advantages.

The actual performance benefits can vary depending on the specific use case, server configuration, and the nature of the web applications being served. While LiteSpeed is designed to be a drop-in replacement for Apache, the choice between the two often depends on the specific requirements and goals of the web hosting environment.

The Litespeed Web Server Offers Additional Advantages.

Although performance is one of the key motiviations behind switching to Litespeed, the Litespeed Web server provides additional advantages. These are:

Compatibility: As I’ve mentioned above, Litespeed is fully compatible with Apache configurations, and it can directly replace Apache without requiring changes to the existing setup. This makes it easy to switch from Apache to Litespeed.
Security: Litespeed includes security features such as anti-DDoS (Distributed Denial of Service) settings, mod_security compatibility, and support for secure protocols like SSL/TLS. Security patches and updates are regularly released to address potential vulnerabilities.
Caching: Litespeed provides advanced caching mechanisms, including built-in support for object caching, opcode caching, and full-page caching. These features contribute to improved website performance by reducing server response times.
LiteSpeed Cache (LSCache): LiteSpeed is often used in conjunction with the LiteSpeed Cache plugin (I’ve written a post covering how to configure the Litespeed Cache plugin for WordPress here). Although this isn’t part of the Litespeed Web Server itself, it can be installed in content management systems (CMS) like WordPress, Joomla, and Magento to make use of and manage caching that the Litespeed Web Server provides. This is often used to improve performance when operating a CMS based site on a server running Litespeed.

Although some of these additional advantages are, again, performance related, the point here is really that it does more than just “install it and things get faster”. An additional security aspect is provided, and also a way for users operating sites to tailor what Litespeed does in the context of their site.

Does the Litespeed Web Server Improve Performance?

What follows is a bit of a “what happened at work”/”how we tried to work this out” type story. If you’d prefer not to have to read the story, you can click here to go straight to the does Litespeed actually improve performance? section.

We had a big discussion at work about this. If you hadn’t already noticed, I work for a hosting provider.

Being nerds, before we did anything we read a lot. There’s a lot of Litespeed Vs Apache type information on the internet. Some of this is somewhat allegorical (such as this post), some of it the performance testing is questionable, some of it looks suspciously biased and in amongst it all there’s some reasonable looking information, but this isn’t consistent. Some is pro Litespeed and it’s performance benfits. Some of it suggest that performance is more application spaecific. Some of it isn’t exactly pro Litespeed.

Then we checked out the pricing.

Although there is a free, open source version of Litespeed it’s doesn’t provide the same caching mechanism that the paid version of Litespeed does. As the caching is one of the factors that can improve permformance, if you want the full benefits of Litespeed in this capacity you have to pay for it.

Due to the cost involved with the paid version of Litespeed, the discussion we had at work was mostly along the lines of “is it going to be worth the cost”.

On one side of the discussion, there was the argument for an improvement in performance without any of our customers having to do anything. We get quite a lot of “my website is slow” queries at work, and the argument was effectively that we could pay to address these, and also gain a reputation as a “faster” hosting provider. This reputation, we’re fairly sure, plays a part in retaining customers.

On the other side of discussion, there was the argument that if a web application has been poorly set up, or generates bloated page output, that Litespeed wouldn’t make much of a difference (so we’d have to pay only to find out that slow sites were still slow). That the speed issues should be addressed within the web application itself, and that there may be some tuning carried out servr side to negate the need to improve performance by using Litespeed.

In the end, we agreed that we should probably do some testing to work out the best course of action. Who’s site was it that we’d use to test this? Yep, you got it: This one.

Luckily, one of our customers has their own server, and they’d installed Litespeed on it before we had this conversation, so we could use this as an approximation of what could be acheived using Litespeed as far as performance benefits were concerned.

We also run cPanel’s default stack (Linux, Apache, PHP and MySQL), so there’s quite a lot of documentation and support forums to hand that covers this as well.

To cut a rather long story short, a lot of the information on cPanel’s support forums, specificially with regard to server response times was along the lines of “the speed issues should be addressed within the web application itself”. You can see what I’m referring to on this cPanel support article about reducing a site’s TTFB (time to first byte). The last paragraph of this page reads:

The only way to “speed up” PHP processing would be to improve the code itself or provide it with a faster processor. Even then, best practices for web applications are to use heavily caching mechanisms. Whether or not you can take advantage of those caching systems is dependent on your web application and if its designers have coded support for it. Only the developer of the site will know more information.

So my boss pointed at me, then pointed that the paragraph above, opened a new browser typed my site’s address in the address bar and said, “you do thing.”

So there I was, running this:

time curl -o /dev/null -silent –resolve someguycalledralph.co.uk:443:185.229.21.109 https://www.someguycalledralph.co.uk:443

And I was either getting a TTFB of 2.4 – 2.8 seconds if my site had recently been visited or a TTFB of up to 8 seconds if my site hadn’t been recently visited.

How embarassing.

I did the same curl test on some of the sites running on the customer’s server where litespeed had been installed. They were mostly around the 1 second mark, or slightly less.

How embarassing.

So I tried all sorts with my site, code profiler, MySQL query monitor, uninstalling every plugin that I could. To be honest with you I wasn’t making much progress.

Then I thought “hang on, the site uses the database to generate page output… what if I test with some PHP that doesn’t?”.

So I made a helloworld.php with this in it:

<?php echo '<p>Hello World</p>'; ?>

Then performed the same curl test, but calling helloworld.php:

time curl -o /dev/null -silent –resolve someguycalledralph.co.uk:443:185.229.21.109 https://www.someguycalledralph.co.uk/helloworld.php:443

And I was STILL getting a TTFB of 2.4 – 2.8 seconds if my site had recently been visited or a TTFB of up to 8 seconds if my site hadn’t been recently visited, even though this doesn’t invoke WordPress, or use a database to generate output.

Although nothing had improved, this did tell us something, which was roughly “it’s not the web application”… because there was no application, just one line of php!

We already knew that the increased TTFB was due to PHP processes not being persistent, so initially (as we were using LSAPI in apache) we tried tuning LSAPI including enabling pool mode (as this should provide a persistent pool of PHP processes, and therefore eliminate the 8 second TTFB), which did have some effect, but not as much as we hoped, and the TTFB never got any better than 2.4 seconds.

At this point my boss said “I reckon I can tune the server to get that lower”, and to be fair, he did. Still using Apache, he managed to get a consistent response time of about 1.4 seconds.

Although this was quite an improvement, it was still about half a second slower when compared to sites running on a server using Litespeed.

At this point I should probably mention that you can go too far with the Apache tuning side of things. When my boss carried out one Apache tuning effort, one of the things we saw was a massive spike in CPU usage. What he’d done was along the lines of letting Apache be able to use too many server side resources.

So there can be implications with the tuning Apache approach.

Litespeed’s “it can do more with less” is really where it comes in to it’s own in this capacity as you can gain an improvement benefit without cauing big CPU load spikes, because it’s effectively more efficient.

So what did we do next?

Luckily, you can obtain a free trial license for the paid Litespeed, without having to pay up front. This, and the above, had effectively lead us to give Litespeed a try, which we did.

Seeing as Litespeed was available I thought it would make sense to install and configure the LSCache plugin within my WordPress. The conversation I’d outlined was over the course of about two weeks, so I was keen to take things as far as I could, so I did.

This was the result:

netnerd@NetNerds-MacBook-Pro ~ % time curl -o /dev/null -silent –resolve someguycalledralph.co.uk:443:185.229.21.109 https://www.someguycalledralph.co.uk/helloworld.php:443
curl -o /dev/null -silent –resolve 0.01s user 0.01s system 10% cpu 0.251 total

With Litespeed and LSCache:

0.251 total

Without Litespeed and LSCache (but with an open PHP process and server side tuning):

1.394 total

Without Litespeed and LSCache (but with an open PHP process and no server side tuning):

2.410 total

Without Litespeed and LSCache (but without an open PHP process and no server side tuning):

8.031 total

What this really translates as is that Litespeed does make a difference, when it comes to server response times, and also to page load times. Quite a significant difference in fact, somewhere between a reduced page load time of 97% and 82% based on the response times we were seeing above.

Obviously the site in question (this one) had changed over the course of the testing outlined above, due to the use of the LScache plugin. As I’m a curious type I wondered how bad things would get if I disabled the LSCache plugin in my WordPress, and see what kind of response time I get without it (bear in mind Litespeed is still running on the underlying server). This is what the same test gave without the LSCache plugin in effect in my WordPress:

1.544 total

That’s a worse response time than this:

Without Litespeed and LSCache (but with an open PHP process and server side tuning):

1.394 total

So one might argue that you can get better results by tuning Apache, and with a an open PHP process, or persistent PHP processes.

This is where things get a bit sticky. It’s those persistent PHP processes remaining open that are thesticking point.

I’ll be honest with you here, at this point we’d spent about 3 weeks working on this, and we had other things to do other than argue with each other and run tests under various conditions, so we bought a Litespeed license, and moved on to other things. We’d reached a point where we felt that it would be more effective to use Litespeed, and for our customers to use the LSCache plugin (if they wanted) to gain the full benefits of Litespeed, rather than working on making PHP processes persistent.

So does Litespeed improve performance?

You’re likely to see some performance increase by using Litespeed alone.
You’re likely to see a greater improvement in performance if you use Litespeed and the LSCache plugin in your CMS.
It might be possible for you to tune Apache to gain an improvement in performance, but this is unlikely to be as much of an improvement compared to using Litespeed and the LSCache plugin in your CMS. It’s also possible that other issues (such as CPU load) may come in to effect if you tune apache.
For the tuning of Apache to have a permanent improvement in performance, PHP processes need to persit and be available, rather than a new PHP process starting when your site is requested.
As well as a performance increase Litsepeed does provide other benefits such as anti DDoS and a more efficient use of server side resources.

As you might recall, at the beginning of this section I mentioned there being a lot of contradictory information about Litespeed, and there being differences of opinion in this capacity.

So here’s the thing….

I don’t think anyone is entirely wrong, or right.

If I had to make a general statement about Litespeed based on my recent experiences I’d say the most specific I’m prepared to be is “You’re likely to see a performance increase when using Litespeed, but this can vary, but there’s more to it than this”.

More to it?

Yep, more to it. Specifically: Caching.

Remeber this from way up there?:

Caching: Litespeed provides advanced caching mechanisms, including built-in support for object caching, opcode caching, and full-page caching. These features contribute to improved website performance by reducing server response times.

It’s not just a case of Litespeed being better, or faster. Litespeed also makes use of caching to a much greater degree than Apache does.

Although you can use Object Caching without Litespeed, and also Opcache, and you can also use caching plugins in your WordPress (such as W3 total cache or WP Fastest cache) to generats static HTML files, these are all fairly disparate, separate mechanisms without Litespeed.

Litespeed and the LScache plugin between then effectively unify these in to a common overall mechanism that’s universal to the Litespeed Web Server which is what serves your site when running Litespeed server side.

The integration of LiteSpeed and the LSCache plugin offers a cohesive and server-specific solution that optimises caching processes for websites running on the LiteSpeed Web Server. This integration effectively provides a more unified and efficient caching mechanism, enhancing overall website performance.

Although this does sound very much like “performance is improved my Litespeed” there is more to it than just Litespeed alone, and these “more to it” components (object caching and opcode) can be unified to a greater degree when suing the Litespeed Web Server.

In summary, you’ll most likely have to do more than just run your site on a Litespeed server to gain the full potential benefits that Litespeed can provide.