Essential Performance Tweaks for Your New OS X Server

OS X Server is perfectly capable of hosting multiple websites just fine in its defautl configuration. However, a few minutes spent tuning and tweaking can pay off handsomely, unlocking far more of the hardware’s high performance potential.

Apache

If you take a gander through the default httpd_server_app.conf Apache config file which lives at .../apache2 in the server’s web config directory, you’ll find some surprising settings — default settings which can positively kill performance once you start delivering pages from even moderately busy sites. So that’s a good place to start some tuning.

Each of these settings can be overridden by dropping changes into an include file and then adding a single line to httpd_server_app.conf pointing it to that include file. Although at the moment, everything in /other will get loaded anyway, I believe it’s preferable to add your own include line that will reference a .conf file dropped into /extra, for example right below the Apple-supplied include line which references /other:

# Certain generated config files, such as migrated forward proxy configs from SnowLeopard
Include /Library/Server/Web/Config/apache2/other/*.conf

# Extra performance tweaks
Include /Library/Server/Web/Config/apache2/extra/httpd_grm_performance_tweaks.conf

Let’s take a look at each setting that needs modification.

MaxKeepAliveRequests 100

The server is already set with KeepAlive on, and this MaxKeepAliveRequests limits the number of requests per persistent connection. Assuming you’re running a newish server, this value can probably be bumped up slightly to 150.

KeepAliveTimeout 15

This sets the maximum number of seconds to wait for another request from a given client on a given connection, and it is much too high: we don’t want to waste resources waiting this long for idle clients to make a request. This number should be bumped down to 5 or even slightly lower. In fact, if your server is especially busy, you should strongly consider shutting off KeepAlive altogether.

Next up is possibly the single most baffling set of values in the whole file:

StartServers 1
MinSpareServers 1
MaxSpareServers 1

Looking first at MinSpareServers, this directive tells your server the minimum number of idle child server processes which should be kept on hand and ready for use, where an ‘idle’ process is one that is not yet handling a request. When there are fewer idle servers than this value, the parent process creates new children at a maximum rate of 1 per second. In other words, it doesn’t matter how fast your server is, when it comes to creating new children processes, it will never happen any faster than 1 per second. So why would we only want 1 extra on hand? Ummm…no idea. Depending how much RAM your server has, this number should be bumped to 20 or 25. Then MaxSpareServers — which controls how many idle processes can sit around before being killed — should be set to double that number. Then StartServers, which is the number of child processes to be created at startup, should be set to the same value as MinSpareServers.

Last but not least, the following default seems extravagant to me:

MaxRequestsPerChild 100000

After this number of requests, the child process will close down and respawn. Since child processes consume more memory the longer they are used, unless we are very confident that there will be no memory leaks, it seems odd to use such a high value, which is higher by one or two orders of magnitude than most recommendations I’ve encountered. You may wish to drop this to 1000 or 2000, depending on your server’s available RAM.

These modifications can all be dropped into the single include file, which will then look like this (together with an extra directive to shut off the server’s signature on server-generated pages such as internal error documents):

MaxKeepAliveRequests 150
KeepAliveTimeout 5
StartServers 20
MinSpareServers 20
MaxSpareServers 40
MaxRequestsPerChild 1000
ServerSignature Off

Setting a Default Favicon.ico and Robots.txt

In addition to tweaking the underlying configuration of Apache itself, you might also want to add a couple of extra directives to your performance tweaks include file to give your server a fallback option for delivering favicon.ico and robots.txt files when these are not present within a virtual host’s directory. This can prevent a whole slew of unnecessary 404 errors (all of which get logged, of course) for virtual hosts where you haven’t yet set up a custom favicon or robots.txt file.

Following the great suggestion given here, you can simply set an alias for default versions of these files stored somewhere convenient, and then return those files whenever the virtual host doesn’t have one of it’s own:

Alias /default-favicon.ico /path/to/favicon.ico
Alias /default-robots.txt /path/to/robots.txt

<FilesMatch "(favicon\.ico|robots\.txt)$">
	RewriteEngine on
	RewriteCond %{REQUEST_FILENAME} favicon\.ico$ [NC]
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteRule .* /default-favicon.ico [L]

	RewriteCond %{REQUEST_FILENAME} robots\.txt$ [NC]
	RewriteCond %{REQUEST_FILENAME} !-f
	RewriteRule .* /default-robots.txt [L]
</FilesMatch>

Again, these directives can simply be added to the include file you’re using for performance tweaks, and they will take effect when Apache is restarted.

High Performance Mode

(Update, 25 March 2016: See “Server 5.1 Brings TLS 1.2 at Last” for more on limitations to performance mode under El Capitan.)

As far as I can tell, Apple provides no detailed documentation as to what this setting actually does, but they do document the existence and basic controls for OS X Server’s high performance mode.

To get the current mode:

To set the high performance mode:

And to disable high performance mode:

Each of the changes requires a restart to take effect.

APC Opcode Cache, Basic MySQL Configuration and More

The next article runs through the process of installing the APC opcode cache for PHP on OS X Server, which for an investment of a few minutes can give a massive boost to PHP performance. Later articles cover performance improvements specifically for Windows visitors, plus server-wide ban lists, modifications to logging, and more.

In addition, if you haven’t done so yet, this is probably also a good time to ensure that MySQL’s configuration is at least in the ballpark, with some of the essential configuration changes that I mentioned in the earlier article on the topic. (See “Installing, Configuring and Performance Tweaking MySQL for OS X Server”.)

• macOS
• page speed