webserver

It’s no secret that I love using the Directadmin control panel. The interface is very simplistic, and can be archaic at times, but it is very stable, fast, and extremely customization when using the Custombuild 2.0 scripts. Recently, I did just that to deploy Nginx as the back-end web server, instead of the default, which is Apache. Nginx is very fast and performs very well under heavy loads. After migrating serenity-networks.com over, I quickly noticed that none of my links are working. Because I use WordPress, I instantly knew it had something to do with .htaccess or permalinks. The first thing I did was set permalinks to default, and everything started working again. Nginx does not use, nor recognize .htaccess files, which are imperative to URL rewriting, and therefore permalinks. So, I had to figure out how to solve this issue using configuration parameters in the Nginx.conf file. But, this isn’t very straightforward with Directadmin. Here is how to do it.

How to get URL rewrites and WordPress permalinks working with Directadmin, Custombuild 2.0, and Nginx:

The first thing you need to know is how Directadmin handles Nginx configuration files. This is pretty simple. It’s done on a per user bases, and the configuration files are located in /usr/local/directadmin/data/users/username/nginx.conf. Pretty simple. Each username has a folder, and within that folder is an nginx.conf file. This is where you can set parameters per user and even drill down to a specific site for a user. So, the first thing we will do is go to that directory, and edit the appropriate nginx.conf file for your user.

cd /usr/local/directadmin/data/users/

Look for the username for your user and cd into that directory. If you do an ls, you will see many different files.

So, you want to build a WordPress server? One that won’t barf all over itself every time a link is posted to Digg or Reddit? Well, you’ve come to the right place. Building an insanely fast web server isn’t rocket science. It’s actually pretty darn straight forward. I’ve built more web servers than I care to remember, which means I’ve also made more mistakes I care to remember. All in the name of trying to make things faster. If speed is your goal, there’s only a few important key things to remember. If speed is absolutely the most critical variable in a situation, my philosophy is something like this:

KISS – Keep It Simple Stupid. Seriously… No control panels, plugins, or other bloated garbage.

FAST Server – This should be a given, but no shared servers. Only VPS, VM or bare metal awesomeness.

Optimization – Optimize, minimize, downsize, and compress everything as much as you can get away with.

Optionally, using a CDN (Content Delivery Network) can really speed things up; as well as a high quality distributed DNS service. But, not absolutely necessary.

Like I said, we’re talking about building an INSANELY FAST WordPress server here. Obviously if you’re Joe Shmoe from Motown, you can probably get by just fine on a quality managed hosting provider, like Serenity-Networks. But, if you want to build the fastest web server on earth, continue reading.

There are plenty of Linux Distributions out there that will work just fine. I prefer CentOS and Ubuntu. For this guide, I’ll be using Ubuntu 14.04 LTS (Long Term Support). This OS will be supported for many years, with security updates. That’s good, especially for a server. If you don’t have it, go to http://www.ubuntu.org and go to downloads, then server. Be sure to select the 14.04 LTS version.

Now, assuming you have done a minimal install of Ubuntu 14.04, with only OpenSSH selected for packages (for remote SSH connection, obviously), we will be using some commonly known building blocks to turn this into a very fast web server.

NGINX Web Server – Many THOUSANDS of the fastest sites in the world use it. It’s the best.

HHVM – This is a very high performance virtual machine that takes care of processing PHP (as well as HACK). Because it turns PHP into machine language, very quickly, it can really speed things up.

MySQL – Kind of boring, but every site needs a database, so we’ll use this one.