Aug 24, 2012
Eugene K

When working with servers, there comes a time when you will always have to make the tricky decisions:

Do I need to use what’s known to be the “right” wheel or rather go with a more advanced option. The advanced option is compiling from source.  That means more control, but also more time invested. Lots of questions will run through your head… things like: How hard is it to maintain afterwards? Today we’re going to cover both sides of the coin, so you get a better understanding on whats involved into the process on *NIX systems.

Stock software or RPM/APT packages.

Throughout the years, the open-source community has maintained RPM packages. Using RPM packages does not require any advanced knowledge of the *NIX operating system. In fact, these options are absolutely loved by users switching from other operational systems, especially when they are accustomed to an advanced GUI, like in Windows Environments. We all like a simple click-and-point, right? That is exactly what RPM / DEB packages (stock) are about – select what to install, and let the software (“yum” or “apt”) do the rest of the job.

If your response to that is “wow, RPM is clearly my best friend for the rest of my life and I don’t want to hear about anything else” then you might be right if you are looking for basic functiaonlity and standard performance. But if you’re looking to maximize the performance of your system, you may want to consider another option.

Stock packages, or pre-compiled packages, tend to subscribe to the thought process of “contain-everything-the-average-user-might-want” – and I do mean everything. That means anything that is commonly used, regardless if you need it or not, will be included in the final software installation. This is convenient, but it also increases resources utilization for no reason, since most of the time you don’t need to install everything under the sun.

I like to think of this as a trunk on a car. You only put what you need in it so you have room to put other stuff down the line. You might have a spare tire, some tools, a flashlight, flare and first aid kit. But in a stock install, it would be full of parts for a new transmission, four replacement tires, every fluid your car might need, extra snow tires, chains, full tool kit, pneumatic bolt driver, and more. Obviously, you won’t need any of this stuff 99.9% of the time, but you might, or another user might, so it is included by default. The same thing basically happens with the systems.

First of all, the stock packages are usually the older stable versions of the software. In some cases “patched” by the OS vendor to fit the current/modern industry standards or to close a security hole in the older software. Nontheless, it’s still older, and the most PCI scanning companies would refuse to mark your website as PCI compliant unless you provide the evidences of the software being patched.

Second, you’ll get exactly a “truck-full-of-extra-tools” if you opt for the stock software. You could use the extra RAM/CPU for the actual website needs – an extra banner, an extra image – all these small things to help you make it profit. But instead, your servers resources are being clogged up by software you don’t need or want.

Third, more software installed means more potential stuff that will need to be maintained and updated later. That can lead to security problems. But if you exclude and only deploy the minimum, then there will be fewer updates for you to worry about down the line.

Compiled from the source software

The words “compile it on your own” usually scare moderate users, even though the entire process is not complicated and, usually, well documented.

The common steps to run the manually compiled software are to update the configuration file, then create the binary files based on the configuration options chosen, then install (aka Place) these compiled binaries to the right locations. That’s a total of just 3-4 commands, commonly outlined in INSTALL or README files coming with the source archive of the software.

The downside to compiling from source

One downside is that you will need to invest time in learning what dependencies the wanted software has and meet its requirements, while the pre-compiled packages already do all of this for you.
However, on the plus side, this is the newer software, patched, likely much more stable, secure and, sometimes – times faster. Would you trade the extra resources availability for the extra time required to compile and install the software manually? It’s definitely up to you, but please check out the differences approached with a bit of extra time involved.

Lab test.

Recently we were testing the startup differences in between the stock version of BIND service on CentOS 5.7 (bind-9.3.6-16.P1.el5) and the latest stable build of the same software from BIND 9.9 tree (BIND 9.9.1-P2); The services were tested on the same environment, serving over 230,000 zone files, so the startup time concerns were extremely high.

Here’s are the results:

Centos 5.7 stock

Starting named: [ OK ]
real 78m45.494s
user 0m58.952s
sys 0m0.280s

and the manually compiled BIND 9.9.1-P2

Starting named: [ OK ]

real 5m18.263s
user 0m5.536s
sys 0m0.299s

That is 10 times faster!

All that extra performance is due to the simple code improvements in the newer version, the startup time lessened for over 10 times, not to mention the memory utilization is lower for over 2G to serve the same number of zone files. Your results with the different software might not be this obviously different, but in certain cases, where your server resources are fully dedicated to serve a specific purpose, it is my strong recommendation to consider the source-compilation of the software as the only valuable option.

Leave a Comment