Litespeed Migration Experience

An overview on my migration to Litespeed Web Server.

It had been nearly two years since one of my sites had been setup on it’s current server, and was experiencing a couple issues leftover from previously-used software and plugins.

Was considering a 100% nginx deployment, due to my positive experiences on this site and another test site running Invision Power Board.

There were problems:

  • with busy forums, with content to share and distribute, continues to be difficult to deliver quickly. It’s easy with some basic forum packages, but motorcycle enthusiasts don’t enjoy basic experiences.
  • nginx could help improve speed, but wasn’t convinced that critical issues wouldn’t be missed that are taken for granted with apache.
  • my CDN provider started supporting HTTP/2. Using a Let’s Encrypt certificate, site performance was improved greatly on images and javascript. Wanted to see how that could be accomplished on the entire site.
  • It was time for SSL Security on my site. Squashed a few man-in-the-middle issues with DNSSEC, but was still seeing content and revenue impacted. However, SSL Security typically means slower website response time. Despite Google’s affinity toward SSL sites, user satisfaction was a greater concern.

Litespeed was worth implementing just on the speed of the sites I visited. Speed alone made it worth the effort. I was also ready to move off of XCache and start utilizing Zend Opcache along with Memcached instead.

Implementing Litespeed at the command line didn’t work for me, because I still use Plesk on that particular server. Test content was working well after I deleted and created a new instance with a installation strategy centered around Plesk first. In other words, install Plesk after the O/S install, and then add-in the Litespeed module for Plesk. Don’t be concerned with the Litespeed traditional install, just insert the Litespeed license key in the appropriate place and it will take care of downloading and installing Litespeed.

Configuring the php items was a bit trickier. It is best to use Litespeed’s pre-built libraries, and after some patience I added in Zend Opcache, Memcached, ImageMagick, Pecl, and a few other items. As of this writing it’s still php 5.6, but version 7 is available.

Speed improvements were quite noticeable when all of content was moved over, and user participation increased. I’ve actually slowed the site back down a bit since, due to being able to re-enable modules that were causing issues before, but the overall user feedback has been very positive.

This post’s picture of Lake Fayetteville was taken a few weeks ago, during most of the effort to get Litespeed stable. My distance dropped a bit due after recovering from allergy issues, but am now going stronger for longer distances.

Litespeed can be found here.


CentOS 7 Differences

I hadn’t thought of it, but realized that my dependence on the version 6.x series represents the most time ever on any version of Linux. Like many others, I was using custom kernels and had a list of nifty tweaks and hacks to squeeze the most out of the OS.

Before making the permanent migration, there were four test instances built using VPS and Cloud Instances from a couple providers. Problems with MySQL/MariaDB and understanding the differences of modern versions of Apache and nginx delayed the migration most of this year. The last test actually ran part of my production applications for a day, but ended up being abandoned due to poor response times.

In the end, I simply used an older dedicated blade and installed CentOS7 on it. Some tidbits noticed and done:

  • Some things work like Ubuntu, guess RedHat likes Debian too.
  • It is more efficient than CentOS 6
  • Need to test MariaDB/MySQL configs. I liked the way I was able to drop my custom config file into a directory (which appears to be common), but avoid running your production data until you’ve got it debugged.
  • My efforts to go 100% nginx weren’t doable, but liked the benefits of Apache 2.4. Still running nginx on static resources.
  • PHP 5.4 for now for compatibility reasons.
  • Stuck with Atomic Linux as well, along with epel, and mod_pagespeed.
  • Service Management was a learning curve for me, this was something I wished had not changed.

Looking forward to continued utilization of CentOS, even though some of the technology I’m using may be showing it’s age.