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?
Nope.
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 hosting 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 systems over 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_type is 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.
Related article: Yahoo’s Best Practices for Speeding up your Website
- I rate the Google Search Query report a solid #/10
- Morgan Tocker Discusses MySQL at Confoo
- Jeff Jones on SEO in 2010
- 7 Tools To Test Your Sites On All Browsers
- Wordpress as a CMS - Wordcamp Montreal Live Blogging
Posted by Samuel Lavoie said on 13.10.08 @ 5:11 pm :
Nice MySQL caching tips that I wasn’t aware of!
For the code clean, this can be easily fix will with good front-end developer for clean and validate HTML/CSS/JS
About the load balancing, I will add that some services like Amzon S3 can offer you that scalability. Nice post.
Posted by Lori MacVittie said on 14.10.08 @ 8:16 am :
A very nice list of ways to help scale your application to withstand a Digg/Slashdot/Fark explosion.
The only point with which I would disagree slightly is around compression. Server-side compression can actually inhibit performance depending on the link speed of the client. In general it should provide better performance, but for scalability it can be a negative.
It’s also important to look at the content types before deciding to apply compression. Image heavy sites will benefit very little from standard web/application server compression as those formats are generally JPG/GIF and already fairly compressed. Text heavy sites, however, will certainly benefit from compression, with the aforementioned caveat regarding link speed.
If you end up using a load balancer, make sure it’s capable of applying compression based on link speed to solve that particular problem.
Again, great tips. Nice article.
Lori
Posted by Janis Lanka said on 15.10.08 @ 12:38 pm :
How about hosting assets on Amazon S3? Would do the trick as well.
Posted by Lori MacVittie said on 15.10.08 @ 12:42 pm :
@Janis,
I like the idea of using cloudbursting better than hosting all assets on S3. You may not need that kind of capacity year round, but when you do - it’s essential.
The concept of cloudbursting really makes leveraging the cloud (S3) a viable option for just such a situation. You pay for it when you need it, and not the rest of the time.
Cheers!
Lori
Posted by Janis Lanka said on 15.10.08 @ 1:08 pm :
@Lori, I have not personally worked yet with S3, though a project that will require lots of photo upload/download is on the way. We are considering using S3 as the storage simply b/c then you have the whole Amazon network taking care of your files. And cost wise, it doesn’t seem that much more expensive than other hosting services (i’m not talking about $5/year ones
)
Posted by Lori MacVittie said on 15.10.08 @ 1:11 pm :
@Janis,
That’s an intriguing use case, actually. Are you planning on leveraging S3 for everything or just the photo storage and integration?
What? It’s more than $5/year???
Seriously, any hosting service providing enterprise-class services had better charge more than those serving consumers. Or prosumers.
Lori
Posted by Janis Lanka said on 15.10.08 @ 2:26 pm :
@Lori, I would only store photos on S3, but everything else (html, css, js, scripts, etc.) from the main server. That way you have two servers taking care of you.
Posted by Remi Turcotte said on 15.10.08 @ 5:33 pm :
i would say : buy another server. lol just kidding.
Posted by CD Junior said on 20.10.08 @ 12:02 pm :
load balancing rules Bay BE. If you can afford it.
Posted by guardianx said on 14.11.08 @ 12:24 pm :
Check out Memcached
Posted by angular cheilitis said on 23.07.10 @ 6:32 pm :
I vote for the buy another server idea!
Posted by lokjhy46 said on 01.07.11 @ 1:31 pm :
I frankly feel that the details provided is related to nearly everybody . Many thanks .
Pompano Beach FL locksmith
Nashville TN Locksmith
Fremont locksmith
Posted by Best Baby Carrier said on 04.09.11 @ 9:10 pm :
hi!,I like your writing so much! percentage we be in contact more approximately your article on AOL? I need a specialist on this area to solve my problem. May be that’s you! Looking ahead to peer you.