Empty bravado had kept tensions bearable, fear filling every gap in thought and talk. This was what they wanted, wasn’t it? The bait was set, and a confident enemy surged in swift response, ready to rush and crash. Scouts had returned with reports of the massive numbers stampeding, and a question crept into minds of all that stood waiting: would it hold?
How many times have you found a link on your favorite social news site only to click it and find the server unresponsive? Too many times, most of you will say. This problem is far from uncommon, and unfortunately, it’s too often neglected by the marketing crowd, ready to just put a link up and wait for the traffic to roll (read: pile, avalanche) in. The reason is simple: the servers cannot deal with the insanely high amount of hits it gets from Digg, Reddit or any other popular UGC/social media site. So how do you fix that bitter-sweet problem? Is there even a solution, or are you doomed to watch your servers get trampled by the onslaught? Worry not, NVI is here.
There are several solutions. None of them actually guarantee that your server will withstand a Digg push and homepage – in war, there are few certainties – but they will all help. In the examples, we will use a traditional popular setup: PHP 5, Apache 2, MySQL 5 running on a Linux (assuming Debian) server. Feel free to ask questions in the comments – we’ll do our best to explain how you can use our methods in your environment. Obviously, one of the best ways to ensure your server will resist incoming traffic spikes is optimize your (already clean) code, but it’s probably the most difficult, too, and the one you have least control over.
- Use static content
A PHP script will be served at least 2-10 times slower than a static HTML page by Apache. Try to use more static HTML pages and fewer scripts. The lower the processing for your server, the longer it will last. It’s a huge plus if you don’t even throw PHP in the equation.
- Use a PHP opcode cache system
If you can’t use static content, let your web server cache the dynamic content. That way, if the page hasn’t changed, your web server will grab the cached version and output it to visitors, making queries a lot less demanding to your server. There are several opcode cache systems out there, the most popular being APC, eAccelerator and XCache. We’ve had pretty good results using eAccelerator, which is not just an opcode cacher but also an optimizer. eAccelerator typically reduces server load and increases the speed of your PHP code by 1-10 times. Installation is very straightforward and can be done by anyone who has a little experience with SSH, Linux and Apache configuration editing. They also have precompiled binaries available for Windows systems and most Linux distributions. Usage is as simple as installing and binding it with your web server. It will do the rest on its own. There’s a more thorough list of PHP Opcode caching systemsover at Wikipedia. The only problem with this solution is that it requires a somewhat elevated access to the system, most probably superuser, in order to edit Apache’s configuration file and restart it.
- Enable MySQL cache
If your pages use a MySQL database, you will definitely want to activate MySQL cache. The funny thing about it is that it comes enabled by default – but the storage value is set to 0, so it never caches anything. All you need to do is locate your MySQL configuration file (my.cnf) and edit the query_cache_size directive or use the MySQL CLI client to perform this operation:
SET GLOBAL query_cache_size = 1000000;
Using this particular optimization will cache the queries you frequently perform, and will therefore speed up MySQL’s response. You will also want to make sure that
query_cache_typeis set to 1. See the MySQL Reference on Query Cache Configuration for more information. Again, the problem with this solution is that it needs a superuser access: system root to edit my.cnf or mysql admin to edit global variables.
- Enable server-side content compression
People often take this for granted, but content compression is often not enabled. It’s as simple as enabling Apache’s mod_deflate. This will feed your content to a compression engine instantiated by Apache, and output it in a compressed fashion. Most (if not all) of today’s browsers accept compressed content, and can decompress it on-the-fly. This also requires superuser access in order to edit Apache’s configuration.
- Load Balancing
This might be overkill for some of you, but it’s still a great solution for high volume websites. Have your database server separated from your web servers. Even have several database and servers to spread the load. How to achieve such a thing is somewhat out of the technical scope of this article, but your sysadmin should know.