For most of the last two months, I’ve been talking about website performance, specifically as it relates to server response times. I started with a couple of posts about hosting plans and server hardware.
The last few weeks I’ve been talking about server software offering posts on Apache, NGNINX, and IIS. My focus has been on the architecture of each in order to point out their performance pros and cons.
Today I want to talk about one more application for running a server, LiteSpeed, which is a drop-in replacement for Apache. I also want to share a few performance tests I ran on this site both before and after my hosting company moved my account to newer server hardware. First the software.
LiteSpeed Web Server (LSWS)
As I said, LiteSpeed is a drop-in replacement for Apache. If the term is new to you, it means you can replace Apache with LiteSpeed without having to make any other code or configuration changes. Just drop it in and replace Apache.
LiteSpeed can read Apache configuration files. It reads and runs both http.conf and .htaccess files. You can replace an existing Apache server with a LiteSpeed server in a short amount of time, measured in minutes, and with no downtime to your site. It’s also compatible with all of Apache’s core modules.
LiteSpeed also offers a built-in cache, including intelligent caching for .htaccess files so that it doesn’t need to check every directory for the file, removing the performance overhead.
It is proprietary like IIS, but there’s an open-source version called OpenLiteSpeed. The downside to OpenLiteSpeed is that it doesn’t read Apache’s configuration files or completely support .htaccess files. Instead configuration is though a web interface. The cost of the proprietary version isn’t prohibitive at $14/month to lease or $249 to own. There’s also an enterprise version that does more and costs more.
If you happen to use WordPress like I do, LiteSpeed offers a plugin specifically to make use of its cache. I noticed the plugin is listed as active on more than 100,000 sites, with nearly all 5-star reviews.
LiteSpeed’s Event-Driven Architecture
Where LiteSpeed differs from Apache is in its architecture. Like NGINX, LiteSpeed uses an event-driven architecture. Instead of Apache’s 1:1 process to request setup, LiteSpeed can handle hundreds of thousands of requests and connections with just a few processes and since starting a new process is the main overhead on the CPU, LiteSpeed can handle all these connections using fewer resources than Apache.
The event-driven nature of LiteSpeed means it doesn’t interpret PHP and other server-side languages natively. Like NGINX, it passes requests for dynamic content to an external engine which you need to configure. The LSWS wiki has tutorials and I’m sure any host that offers LiteSpeed will set things up for you.
Using external engines you can run dynamic sites that are written with PHP, Perl, Ruby, Python, and Java. Again, you will need to have these engines installed and configured, but LiteSpeed offers help on how and your web host will probably do the work for you.
According to some reports it runs up to nine times faster that Apache and increases the performance of PHP by up 50%. Claims I can’t personally verify, but have come across quite a few times while researching LSWS.
I suppose a good way to summarize LiteSpeed is that it works similar to NGINX and has similar pros and cons, but it was developed to specifically work with Apache configuration files to make transitioning easier.
Once again in order not to make too many mistakes with some of the details, I’ll point you to resources with more and better information than I can provide.
This first group of links points you to information on the LiteSpeed site.
- Event-Driven vs. Process-Based Web Servers
- LSWS Feature Explanations
- PHP Information from the Wiki
- WordPress Benchmarks
- OpenLiteSpeed Wiki
These next few links point to articles about LiteSpeed from a few different hosting companies.
- What Is LiteSpeed Web Server?
- LiteSpeed Web Servers Get More Out of Existing Infrastructure by Delivering High-Performance Caching and Lowering Costs
- LiteSpeed Web Server – Up to 9x Faster than Apache
Performance Testing this Site
In between the performance series I published last fall and the one I’ve been publishing now in early 2018, I had this site moved to a new server within the same hosting company.
I was having some issues with a few things in the control panel for my account and it turned out the reason was due to my account being on an older physical machine with older hardware, which didn’t work with a software upgrade to the control panel.
As a result we, meaning the tech support staff at Webair with me being kept up to date, moved the site to a newer machine. The specs of my account as far as RAM and disk space are the same, but the hardware is newer so I would think the CPU would also be newer and likely better as well, though I forgot to check what the old CPU was before the site no longer used it.
Since I had performance test results from the last series and before the move, I thought I would run the same tests again and compare the results now that the site is running on newer hardware.
I’ll keep the comparison to results for time to first byte (TTFB) and the SpeedIndex measurement exclusive to WebPageTest results.
Here are results from before the move.
|Location||TTFB (2nd, 3rd)||Speed Index (2nd, 3rd)|
|Dallas||1.154 (1.100, 1.706)||2605 (2659, 3193)|
|Paris||1.364 (1.170, 1.394)||2216 (2200, 2246)|
|Sydney||1.556 (1.682, 1.582)||3092 (3169, 3092)|
And here are results from after the move. Previously WebPageTest had one location in Sydney to test. They now offer two and the results here are from the location that showed worse results for the site.
|Location||TTFB (2nd, 3rd)||Speed Index (2nd, 3rd)|
|Dallas||0.613 (0.441, 0.454)||1407 (997, 998)|
|Paris||0.584 (0.670, 0.555)||1414 (1902, 1318)|
|Sydney||1.225 (1.199, 1.128)||2785 (2843, 2698 )|
A few days later I ran the tests again and received similar results so I won’t display the second set, though I’ll mention the second set of results were generally a little bit better, though not much better.
When compared to results before the move, all of the after results are better and I think it’s fair to say much better in the cases of Dallas and Paris.
I honestly wasn’t expecting much of a change given the specs on my account are the same as they were before, but I guess this fits with what I said at the outside of this series about better hardware usually leading to better performance. I meant it in regards to specs, but I think we all know computers age and the same specs don’t perform as well after a time.
Server software probably isn’t the most exciting topic for web designers, but I hope you learned a little about how that software can affect the performance of your site and perhaps I helped you choose your next hosting company and plan.
At the very least you should have a better understanding of what the particular strengths and weaknesses of your sever are and whether or not your hardware or software is the cause of any performance bottlenecks.
This brings me to the end of this mini-series on server software. I have another mini-series on dynamic sites coming in a few weeks, but first I’m going to sneak in another two post series about creativity and productivity.
Download a free sample from my book, Design Fundamentals.