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 ;)

VPS stands for Virtual Private Server, a type of hosting technology that gives you advanced features and server privilege as against a shared hosting. Its use in this article however refers generally to any type of hosting that allows you root access to your server – dedicated servers, VPS itself and Cloud servers as examples. I’d like to explain each in here but that is beyond the scope of this piece. Maybe some other time ;)

If you are proposing a startup or a big site – big in the term of eventual traffic and functionalities, then shared hosting is not the option for you. Really, I’m talking from experience. Go VPS. There are a lot of reasons for this but here are 3 core ones:

1. With VPS, you have the ability to configure your server (app and OS) to your taste, removing and adding stuffs the way you want – and this is a very important thing.
2. On shared hosting, there is a limit to how ‘big’ you can grow. Let me give you a live example here. We started ngBot on a shared hosting and everything was going fine till we added ngBot mobile. The whole idea was a play thing – just a place to share mobile items we get here and there and then meet other mobile geeks, but then it started getting more than that. In a while, we grew close to over 4000 members and was clocking around 30k monthly page views. And that was when the axe came from our shared hosting company. They disabled some of our scripts and advised us to go VPS or dedicated. The blow came so sudden and we had to take off the site for around a month till we found and nested on a suitable VPS host (cloud server actually). Needless to say, the one month the site was out cost us a lot of hits, members and Search Engine ranking.
3. On VPs you do not share resources with anyone like on shared hosting. Shared hostings are like face-to-face apartments where you share a lot of things together and you easily get disturbed by one another. If your neighbour on a shared hosting is a spammer for example, this may affect how mails from your site are delivered as well.

One thing to note about VPS however is that they are costlier than shared hosting. Another is that they require a little advanced skill to setup especially if you go the vanilla blank server way and you are doing the OS, server and tools setup yourself. This is a really big one and I advice you go for the preinstalled/configured option if you are not up to it. The already setup ones comes with an admin app (CPanel mostly) and looks pretty much like your shared platform. With the blank ones, all you have is your ugly shell console to do everything you want. And if this is your way, you will find putty very useful.

Needless to say, a good knowledge of your VPS OS is a very important virtue. As a server admin, you should be very familiar with the OS directory structures, installing/removing packages and dependencies (good knowledge of building and compiling important here as well as build tools like make and gcc), editing config files with editors like vi and nano (as you know, this is very common to Linux) among others.

Another very important thing you should know about is DNS setup (A, MX and CNAME especially) and how to configure your A records with your server especially if you want to setup multiple domains on the server. A good into article on DNS is available here: http://carsonified.com/blog/web-apps/get-started-with-dns/

Now, space and bandwidth is one luxury you don’t have on VPS. It is easy to find shared hosts promising you unlimited space/bandwidth but if you hear that on VPS, run away! The little one we run on at the moment offers just 20GB space as against our former shared hosting space of 1500GB! As a workaround to space and bandwidth issues on VPS, enter CDN (Content Delivery Network)!

CDN serve as storage backbone. Picture the scenario: storing our mobile stuffs (videos, apps, games, pictures) in our little 20GB space will leave us with little space for more upcoming ones. What if we have it stored in a different place – on a different server designed exclusively for data storage and transfer and not for core server functionalities like script compiling/serving etc? And that is what CDN is all about. CDNs are designed as storage servers for static data. But they don’t just store. The way they are designed is such that they distribute stored content between different other servers around the world and serve content from the server closest to the request source, making content serving fast. Not only that, CDNs also enable content caching.

You come across CDN in use every minute you surf the web – Facebook (for storing/serving images/videos), twitter (for storing profile images), ngBot mobile (serving mobile download files) ;) and a lot more. Another good thing about CDN is that you don’t have a specific size you are limited to. You can consume as much as you want to as you pay per GB of space you use. Much more, it is cheap – very cheap. On the one we run on (Rackspace cloud files), 1GB costs around $0.15. One of the most popular public CDN is Amazon S3. They have been around for quite a while and a lot of sites use it, twitter as one. Another is Rackspace cloud files (which we use) and the new Microsoft Azure.

So how exactly do you transfer content in and out of a CDN? What other ways are static content served? Why is it necessary? Where does caching comes into this? Join me in the next piece ;)

Post update: The Second part of this article has been published here.