History of web servers (and transition from Apache to NGINX/LiteSpeed)

Quick breakdown of the evolution from Apache to NGINX and LiteSpeed.

Apache was the first

Apache web server (started 1995) came first. I believe it was the first one to make Linux the standard for web servers. High performance, highly-configurable, secure. All that good stuff. Everybody knew how to use it. Everybody was used to it. Apache servers, configurations, and general guides are still in circulation today. Web-servers back then were pretty easy to manage.

WHY?

Because websites back then were mostly static. Only text and inline-styling. No complicated CSS, or JS. Hahaha. No dynamic PHP and MySQL database. Not much processing. Just processing text in your browser DOM and that’s it. Very static and the only complications were in the visual rendering.

But then what? Websites started getting more complicated. Sites weren’t simple pages of text anymore. You had CMS. You had USERS logging in and out of sites. Not everybody saw the same thing or even on the same day. Sites were like programs (web applications’, if you will). You could search for a car, or play a game, or upload and manipulate a picture, and so forth. You had content that was changing. All this needed PHP and mysql databases…this way you could query the specific data for the specific request. Websites were now becoming apps.

Dynamic content is slow…

…because there’s processing involved. It’s the difference between having an address already written down VS having to call someone to ask for it. So what do you think happens when you try to speed up dynamic content? You start to CACHE it. Caching is basically turning the most common parts of dynamic content into “static content” so that it loads faster.

NGINX – king of static content

NGINX (started 2004) was a simpler and more lightweight server than Apache, focusing on only the most essential web server functions and very high-performance at what it did. Out of the box, it could serve static content using far less resources than Apache did. Apache uses more memory because it does more things. Apache does like a 100 things whereas NGINX only does like 6 (but the most essential ones for a web server).

It is the most popular web server among the largest sites today. Reasons why? Fast, free, admin-friendly, open-source, supported and backed by large corporations. NGINX had a completely different set of configurations and logic. It requires some new understanding. Not so hard but can be a learning curve for the old Apache-diehards. There’s something refreshing in in technology when it’s written completely new from the ground up. Old legacy code is thrown out, and only the essential remains.

Most sites still used either Apache or Apache+NGINX

Some websites either could not work with NGINX or for whatever reason, still preferred to have Apache in the web-server stack somewhere. And so instead of relying purely on NGINX, there was a long period of hybrid web server stacks like Apache + NGINX. Or they would call it Apache w/NGINX proxy. Basically, NGINX was the frontend server caching and serving static content super fast. Anything that had to be dynamically processed would be passed onto Apache (as the backend server). This stack also had the benefit of being htaccess compatible.

The benefit of this hybrid stack over Apache-only stack was:

• High-traffic sites – NGINX took the blunt of the static traffic, while Apache assisted with dynamic traffic.
• Low-traffic sites – APACHE took the blunt of the dynamic traffic, while NGINX allow faster loading for repeat (cached) page visits.
• Depending on how you value “complexity”, this stack could scale easily into separate servers.

But still. There were lots of variations within this:

• Apache without Varnish
• Apache with Varnish caching
• NGINX with Varnish caching
• Apache+NGINX with Varnish caching
• Apache+NGING without Varnish caching

There seemed to be many configurations, sometimes requiring careful laying and tuning. And deciding which stack was best for you depended on your type of website, type of traffic, and also your (or your admin’s) skill. Ideally, you’d like a simple stack without much complexity and configuration.

Apache refused to die – diehard stance

Even as NGINX was becoming more and more popular, there were still many Apache-diehards arguing it could be just as performant as NGINX “if only it was configured right”. (Do remember that phrase, it will repeat later.) And there was truth to it. Benchmark battles went back and forth as the endless comparisons waged on for years. The addition of 3rd-party performance plugins and modules for both sides made apples-to-apples comparisons virtually impossible.

• “Stock NGINX beats stock Apache in [this] scenario.”
• “Stock Apache beats stock NGINX in [this] scenario.”
• “But Apache+NGINX beats pure-Apache or pure-NGINX in [this] scenario.”
• “But Apache+NGINX is only helpful if you have Varnish.
• “But you don’t need NGINX to have Varnish with Apache.”

Blah blah blah, it goes back and forth. And as time passed. It didn’t matter much, anyway. NGINX’s native FastCGI cache which was quickly superseding the archaic and needlessly-complex Varnish. And despite Apache’s improvements, it simply couldn’t shed the weight to compete against NGINX. Apache was simply a server that was meant to do a lot of things. If you don’t need to do even half those things, you don’t need Apache. The introduction of virtualization and VPS (smaller dedicated instances with lower memory resources) only further exacerbated Apache’s resource-gluttony.

Regardless of which side you were on, one thing is for certain: it takes less skill to create a high-performance NGINX stack than it does to configure an equally-performant Apache one. NGINX just seemed fast and lightweight out of the box. Apache seemed like a brand new Hewlett Packard desktop computer from the store, full of pre-loaded crap that you had to remove.

Apache’s notoriety out-of-the-box bloat made it an open target for web server benchmarks. Just about every web server out there brags how it’s “X times better than Apache”. A metaphorical bullseye on the back of your head, if you will.

• NGINX is 3 times faster than Apache!
• LiteSpeed is 3 times faster than Apache!
• Tomcat is ___ better than Apache!
• Caddy uses less memory than Apache!
• and so forth

But then we have “Apache is Still the Best General-Purpose Web Server” written in 2018.

LiteSpeed’s – the Apache replacement

LiteSpeed (started 2003), similar to NGINX, also started as an improvement over Apache but developed mostly out of the limelight. Instead of cutting out Apache’s web server functions entirely, found its niche in being backwards-compatible with Apache so it could be used as a drop-in replacement without losing any Apache functions. In this goal, it achieved exactly that…a high performance web server that could be dropped in as an Apache replacement. For large companies with Apache deployed extensively throughout their stack, LiteSpeed was a gift from the heavens whereas NGINX felt like remodeling your whole kitchen.

Comparing LiteSpeed to NGINX

For a someone wanting to host just websites and custom-written applications, NGINX was favored for its performance and free-cost. The performance difference between NGINX and LiteSpeed was comparable. If I had to guess, NGINX probably had the edge.

But for someone wanting to host software specifically written for Apache (which was many web software at the time), LiteSpeed was the only easy option if you wanted higher performance. Either switch out Apache for LiteSpeed and you get to keep your software…or get NGINX and you may have to get entirely new software.

In a way, you could say that Apache and NGINX were somewhat like different web server operating systems (like Windows and Mac OS X)…and that sometimes software existed for both platforms but other times only for one. Being that Apache was #1 most popular web server (it still is today), you can only imagine that most software written out there was for Apache. Custom-written software however, I feel was more often written for NGINX as it seemed NGINX was simpler/leaner and the future of web servers.

For many years, nobody really cared to compare NGINX and LiteSpeed. They were different enough not to overlap in preferred use cases:

• LiteSpeed was a commercial product (costs money), compatible with Apache/htaccess. Great for shared webhosting scenarios where newbie users relied on Apache-friendly control panels and Apache configurations (htaccess), or large high-traffic websites supported by experienced Apache admins/engineers.
• NGINX was a free product, simple to install and run. Great for quick command line deployment for small sites, or large high-traffic websites supported by experienced NGINX admins/engineers.

Apache still not dead

Meanwhile, the old champion is still trucking along and STILL the #1 most popular web server (Apache 40%, NGINX 30%). They just weren’t the trend anymore. For the rest of this guide, I’ll ignore Apache but leave a few outstanding points:

• Some claim Apache is STILL a good web server and extremely powerful. I’ll take that to mean “tons of features but will bloat if you don’t manually tune them.”
• Others will also say Apache is still a great server and can play nicely with NGINX if you need. I somewhat agree with this.
• Ultimately, I think if you’re good enough to argue the case…you’re good enough to argue in Apache’s favor for your use case. For everyone else, Apache is just bloat!