When Application Tuning Becomes Network Optimization
Software engineers are adept at finding performance bottlenecks in their code, application servers and databases. When those application components have been tuned but performance problems remain, the network becomes a prime suspect. Before you dismiss your network performance problems as something you can live with, consider the adverse impact slow application response times can have on your business.
A study by Gomez.com found a 38% jump in page abandonment rates when response times increased from 2 to 8 seconds.The same report notes Aberdeen Group found a one second increase in response time reduced conversion rates by 7 percent, page views by 11 percent, and customer satisfaction rates by 17 percent. Slow Web applications are all too common. Equation Research found 67 percent of Web users encountered slow sites at least once per week and 37 percent admitting it left them less likely to return.27 percent were so put off by bad application performance that they were more likely to visit a competitor site in response.
How can you keep your applications providing acceptable response times?
The first place to start tuning is the application.Obvious candidates for tuning are database queries and data caches. These can minimize the number of I/O operations you have to perform. Also consider your application architecture. For example, are you using load balancing effectively? Is your storage system providing sufficient I/O operations? If you have tuned your application code and taken advantage of well designed architecture and your overall application performance is still lacking, then it is time look into network issues.
There are a number of different ways your network can compromise your overall application performance. Your servers may be competing with significant volumes of other traffic.One option is to increase the bandwidth on your network, and while that may be a viable long-term solution, it may not always be a practical option in all cases. Network administrators may be able to isolate your application servers on their own segment that can help reduce contention for limited bandwidth. Bandwidth is not always the problem though.
When the goal of tuning is to reduce application response time, then you should consider latency as well. This is typically measured in round trip time (RTT) - the time it takes to send data to a device and to receive a response.
It is important to remember that even with sufficient bandwidth you may have long latencies. Increasing your bandwidth will not help improve latency when you are not utilizing all the bandwidth you have already. If your application has periods of peak bandwidth demand, such as during large file transfers or when streaming video, then your additional bandwidth may help. In typical Web browsing and transaction oriented operations latency is more likely to cause problems.
Dan Sullivan is an author, systems architect, and consultant with over 20 years of IT experience with engagements in systems architecture, enterprise security, advanced analytics and business intelligence. He has worked in a broad range of industries, including financial services, manufacturing, pharmaceuticals, software development, government, retail, gas and oil production, power generation, life sciences, and education. Dan has written 16 books and numerous articles and white papers about topics ranging from data warehousing, Cloud Computing and advanced analytics to security management, collaboration, and text mining.
See here for all of Dan's Tom's IT Pro articles.
(Shutterstock cover image credit: Radio Display)