Reach Higher Scalability from your Web Applications
Tuning vs. Adding Additional Hardware

When the performance of a web application starts to degrade, often IT managers jump to the conclusion that more hardware is required. This increased infrastructure can be expensive and may not even solve the underlying problem. Let’s talk about tuning as a solution to higher scalability. It’s been debated as to whether tuning is a science or an art but we can all agree on the goal: alleviate bottlenecks so that the web application can scale to a higher workload. Tuning is more efficient and cost effective than adding more hardware to your deployment. However, you need to have the right tools and expertise in place in order to successfully tune an environment.

Hardware servers are restricted to their physical resources (io, memory, cpu, et). With OS tuning, there are certain buffers and network configurations you can open up to increase overall capacity. Software servers are even more configurable because they use their own thread pools, caching, memory management, connection pools, etc. All of these software resources do actually run on a hardware server, but tuning software servers can allow it to take more or less advantage of hardware resources.

Tuning can allow or restrict throughput to an environment. Imagine a funnel. The large opening is on top, the small opening is on the bottom. A properly tuned environment will have more processing capacity on the front end (larger end of the funnel) and less dedicated processing at the end. This approach is used for a couple reasons, one is typically the front end of a deployment does more lightweight processing (webserver) and the backend (database) does more CPU intensive and shared resource processing. You want to allow as many requests to be processed on the front end without flooding the backend.

Most people do not know where to begin in the tuning process, so here are some tips to point you in the right direction. First you will need a load test solution which generates a realistic load. The solution also needs embedded monitoring for your entire deployment. For starters, don’t change a single thing! Simply identify and document all the configurable settings for each software server in the environment. You want to be especially aware of the settings which affect throughput – giving the server more or less processing power. For example, a webserver’s worker threads or database and application servers’ memory/threads/pools/buffers. Once you have all the settings documented, then start executing your load tests and monitoring all the configurable resources. Run the tests up to the points of degradation, don’t try to identify saturation points while the test is running, this is far too complicated. Once degradation occurs, stop the test and graph out your monitors. Identify the first major bottleneck, make a change to alleviate that bottleneck, rerun your test.

Keep to a methodical approach, change only 1 variable at a time. It is also greatly helpful if the tool has a built-in comparison analysis engine which visually shows you how your 1 change affected the scalability of your test. Use the load to validate all of your changes. When you are tuning, you need to essentially be aware of two very important statistics: throughput and response time. This is where the art comes in. You need to tune the environment for maximum capacity without allocating too much “work” for the underlying hardware to handle. If you make this mistake, and we all do, you will see the response times increase. Remember, there are limitations in infrastructure. Nothing is infinite. Tune until your workload is using up most of the hardware resources while delivering acceptable response times.

Tuning can save time, save money, and save the planet (greener deployments use less electricity). The costs associated with more hardware are not just in dollars though, it’s also in administration and maintenance. Also, each new piece of equipment is another potential point of failure (we’ve all seen machine’s go down due to myriad reasons). Tuning is typically the best first approach to address any performance degradation. Expertise is in knowing where to look!

3 Comments
  1. May 25, 2012
  2. May 26, 2012
  3. June 8, 2012

Leave a Reply

Your email address will not be published. Required fields are marked *