Five Server Load Tips
Last week, a company called Skyfire launched an app that made it possible to watch Flash movies on an iPhone or iPad. Their app uses servers hosted in the cloud to convert Flash videos to HTML5, making them viewable on iOS devices where Flash is not available.
Now we’ve heard before that nobody wants Flash on their phones, so you would understand that Skyfire had a slow first day after their launch. And by slow first day I mean their servers were so overloaded by the demand that they couldn’t provision them fast enough. Eventually they had to pull their app from the app store and declare it “sold out.”
We here at uTest think that among the things in this world that could be called “problems,” having so much demand that your servers can’t keep up is definitely a good problem to have. Skyfire did, after all, make over $1 million in their first weekend on the app store.
On the other hand, nobody wants their servers to crash because of excessive load. The trouble is that properly planning for heavy load is often something that can vary from one application to another. (The load planning for Skyfire is probably very different from Facebook.) Still, there are some very simple load planning tips that almost everyone should know:
1. Think about memory utilization. Unless your server is a pure Turing machine, it probably has a finite amount of memory. If you exceed that memory limit, most operating systems will begin using swap storage on disk to simulate more memory. That’s great at preventing your server from running out of memory, but swap storage is really slow. In fact, if a key component of your application stack (such as Apache or MySQL) has to swap, then you’re pretty much doomed from a performance point of view. Instead of allowing that to happen, set the memory limits on your server applications so that they can’t exceed a certain size. As your server hits peak load, clients may still have to wait for service; but that wait time will be much shorter than if the server app has to swap.
2. Use caching where it makes sense. You can improve a lot of your server’s performance if you can cache certain things that don’t change that often. For example, if you have to render the same block of HTML using server side scripting every time a visitor hits your site, at some point it just makes sense to render that block once and then serve static HTML for every new pageview.
3. Check out Google’s mod_pagespeed for Apache. Google has developed and released an Apache module that implements over a dozen tricks and best practices for improving server performance, all in one convenient piece of software. Not all of them are appropriate for every user, so they also make it easy to enable or disable certain components of the module.
4. Use a content delivery network for static content. Content delivery networks (CDNs) take your data and replicate it to servers around the world. That puts your data closer to your end users, which makes it much faster for them to load your content. Using a CDN can also reduce your server load because you’re no longer serving a lot of that content yourself. Just a few days ago, our VP of Engineering showed me a chart showing our platform server load before and after they started using a CDN. The drop in load was so huge, you could have base jumped off that chart.
5. Test, Test, Test. Most of the time, you can’t predict where your performance bottlenecks will appear. When it comes time to find out what’s really slowing down your server, you have to actually test your application by loading it down. Often times, the results of load testing can be very surprising to developers – many of whom spent more time optimizing other components.
Of course, we should point out that we happen to know a good load testing company. Also, if you just want to learn more about testing, check out our load testing whitepaper for some great tips on getting more bang for your buck from load testing.
