In this piece, we will focus more on scalability – which I simply define as the ability of a server to efficiently adapt to more load. It is more complex as that sounds and to know more, you can check out scalability @ wikipedia.

As a server administrator, optimizing your site and server for scalability is a task you will face occasionally, if nor more often than that. At first, with just a couple of site visitors and members, all may seem well. But as users and visits grow, you will start finding the need.

There are two types of scalability actually – scaling out which is about adding more system nodes, like buying more servers and scaling up which is about effectively maximizing the potential of what you have on ground already. Scaling up is cheaper than scaling out, in fact, in some instance doesn’t even cost any dime – and this is what we are looking at here. Besides, if you start with scaling out, without scaling up, there is the every posiblity you will continue scaling out as just a little wrong thing with your app or server configuration may be causing excessive load and weighing down the server – a problem scaling out won’t solve. Scaling up on the other hand will let you detect such. After properly scaling up, you can then scale out.

So the big question – how do you scale up? And to that is a lot of answers. Yah, there are many ways to optimize your app/server – every single way you think can save the server memory and number of processes. Some of this include caching, code optimization, profiling and even good configuration of your server and database engine. Caching alone as a big parent, has a lot of children – setting proxy servers, database caching to mention just two.

In the last piece I mentioned CDN (Content Delivery Network), and even this is a great scalability technique. I guess I do not need to recap the advantages here but having your static files served from a different server entirely saves your deployment server (your app server) more memory and processes, leaving it to take care of more important files (dynamic content for example). Mind you, your static files include your CSS, javascript, images, flash and co. At ngbot (mobile, ads, answers) though, we don’t store our CSS, JS and all images in our CDN but there is a simple caching technique we use to reduce the effect of serving it from the deployment server, which I will talk about in a gifi.

Continuing from where I stopped on CDN in the last piece, how do you get content in and out of the CDN? It is simple – APIs. CDNs provide APIs you can interface directly from your application. Most providers even offer code libraries in different programming language to help out. Rackspace (which we use) for example has a great php class implementing the api. It is simple. You simply authenticate with some already provided details and you are good to go.

Below is an example code excerpt

include 'cloud/cloudfiles.php';
# Authenticate. CLOUDUSER and CLOUDAPI predefined with define()
$auth = new CF_Authentication(CLOUDUSER, CLOUDAPI);
$auth->ssl_use_cabundle();
$auth->authenticate();
# Get Container obj
$conn = new CF_Connection($auth);
# Get container named 'static'. NB: container = folder
$container = $conn->get_container('static');
# Public?
if(!$container->is_public())
{
	# make public and cache content for a day
	echo $container->make_public(86400).' : '.$v.'
';
}

Note the cache part where you can set the content to be cached on the user’s system for a number of seconds (8400 in the example = a day). By such, the content is stored on the user’s system for the specified duration and won’t be requested again from the CDN during that time. This consequently saves your CDN traffic and saves you money.

Ok, CDN settled, lets see other ways to serve static content from your server, as we do for our css, js and some of our image files. To start with this is specific to the Apache web server. There are ways to do it with other servers though.

The technique is based on caching. If you serve just static pages in your site (which I doubt) you can actually set your server, Apache in this case, to cache the site content for a specified duration. For people like me who have issues with caching all content and setting up proxy servers however, there are ways to cache some specific content by content-type. It is called Mod Expire in Apache and you can read more about it from the Apache docs

In general, here is what it looks like (in htaccess).

ExpiresActive on
# Images and flash
ExpiresByType image/png "access plus 2 month"
ExpiresByType image/gif "access plus 2 month"
ExpiresByType image/jpeg "access plus 2 month"
ExpiresByType application/x-shockwave-flash "access plus 2 month"
# css may change a bit sometimes, so dont cache too long
ExpiresByType text/css "access plus 5 days"
# special MIME type for icons in case not set yet
AddType image/vnd.microsoft.icon .ico
# now we have icon MIME type, we can use it
# But my favicon doesn't change much, so say 3 mnths
ExpiresByType image/vnd.microsoft.icon "access plus 3 months"
ExpiresByType image/x-icon "access plus 3 months"
# JS? A month will do
ExpiresByType application/x-javascript "access plus 1 month"

I’d love to go on and on, but again, let’s leave it at here. Don’t forget however that scaling is about sniffing and optimizing every little thing that will weigh down your server, starting from checking your server (e.g Apache) and database (e.g MySQL) configuration. If you are using a framework, especially for your server side, you should be sure you set things up properly. Even at that, be sensitive to page load speeds and memory consumption. You can check out your server memory consumption and other vital details with the Linux command free from shell. If you are not much of the shell/console type, there is phpSysinfo which displays vital system info in a web page format.

And finally, talking page load speed, output compression is a life saver. By compressing content sent to the http client (say browser) from the server, you can drastically reduce your page load time. We use prototype as our parent js framework wich is quite heavy – around 74KB minified. Think of how long t will take this alone to load not to talk of other scripts. However, by output compression, the file is reduced to just around 21KB.

Output compression is a very easy thing. Note though, it is an extra work for the server so be sure of the trade off. In Apache (2.x), it is as smple as something like this: (Read more here)

# Compress javascript and css files
AddOutputFilterByType DEFLATE application/x-javascript text/css

Compressing a PHP file on the other hand is as simple as adding the line below just before any output buffering (any content is displayed/echoed)

ob_start("ob_gzhandler");

Ok, that’s all for now. Hope you’ve been able to learn a thing or two. Catch you later ;)