Stress Testing Linux Web Servers

Many businesses depend on their servers and the sites they serve to generate revenue. Comprehensive testing using a selection of the tools we’ve covered here is critical for avoiding lost revenue and the embarrassment of downtime.
Anyone who has been responsible for the roll out of a new website or app will understand the apprehension that is the inevitable result of watching the first cohort of users hit their servers after a feature update. For a web service of any significant level of complexity, there’s a non-trivial chance that a coding error or unforeseen combination of circumstances will result in performance issues or availability problems. Even the big guys like Amazon and Google get wrong-footed on occasion.
While it’s almost impossible to foresee every eventuality, if web developers want to avoid the embarrassment of a non-functioning site, particularly when they’re in the midst of a marketing blitz to publicize their business, they need to exhaustively test their code before launch time. That’s often easier said than done: however solicitously they review their code and infrastructure, real world conditions frequently reveal edge cases that lead to unforeseen bottlenecks and other inefficiencies.
Fortunately, there are a number of tools that allow developers to run simulations on their sites to determine how they function under real-world loads.

Gor

Testing real world conditions is a two stage process. First, developers have to somehow build a simulation that adequately mimics those conditions, and then they need to apply that simulation to their server. Clearly, doing this in a production environment isn’t ideal, so having both a staging or testing server to which changes can be pushed is preferable.
Gor is an HTTP traffic replication tool that allows developers to replay traffic from their production servers to their testing server. It’s a fairly simple application that consists of two parts; a listener that is attached to a port on the production server and a replay component that sends all traffic received on that port to the testing server, allowing developers to build an accurate model of how their production environment will respond once their testing and production servers are synced.
Gor is capable of rate limiting the traffic replay, so that high traffic sites can replay a sample of real world load without overloading their test environment.

Siege

Siege is an HTTP load testing tool. It is a more complex tool than Gor, and allows developers to simulate a number of web clients and direct them to hit a site with requests to give them a good idea of how their code will stand up under load spikes.

Gatling

Gatling is another stress testing tool but it is specifically designed to allow developers to test the interactive features of their site. Gatling allows developers to create multi-step recipes that to run through interactive processes on a site: the checkout process for an eCommerce store or an account creation workflow, for example. It’s a great way to focus testing on a new complex site feature before deployment.
If you’ve had experience with these tools or want to join the conversation, leave a comment below.

About Rachel Gillevet – Rachel is the technical writer for WiredTree, a leader in fully managed dedicated and vps hosting. Follow Rachel and WiredTree on Twitter, @wiredtree, Like them on Facebook and check out more of their articles on their web hosting blog, http://www.wiredtree.com/blog.

6 Comments

  1. Hello Rachel,

    May I advise you to have a look at commercial performance testing tools too on top of the one listed.
    Indeed HTTP request generators may well prove sluggish to simulate real-life tests that really contribute to risk reduction.

    To be honest with you, I work at Neotys, editor of NeoLoad. NeoLoad is a load testing solution (trial version is free http://www.neotys.com/product/overview-neoload.html) designed for web applications to realistically simulate users activities and monitor servers behaviors.

    Simulating realistically users activities raises the need to variabilize the requests sent. For instance, dynamically changing the value used in a datapool, or dynamically checking what the values received are (e.g. item id in a ordering system), extracting these values with a reg_exp based mechanism, and using it for the other requests.

    Performing realistic performance tests also involves simulating the network conditions of the users who make the requests. Reproducing different network conditions (latency, bandwidth, and so on) is key to significant "real-life" tests.

    Regards

    Hervé Servy, Neotys Performance Engineer

Leave a Reply