Performance Tuning
"More hardware!"
If only it were that easy. Sometimes there is only one box. Sometimes every additional box comes with unacceptable license costs. Perhaps the problem is in the database layer, or with an application so memory-inefficient that it blows out the JVM and crashes eventually on every box. Maybe there is a firewall configuration issue causing the Web server to lose contact with the application servers, no matter how many of them there are. Or maybe there are just too many layers, adding too much latency to every request. We have seen all those issues and more on performance-critical projects such as:
- Implementing real-time trade verification for a stock exchange
- Tuning an equities-trading system for a major Wall Street brokerage
- Selecting and proving the Web architecture for one of the biggest Toy stores on the Internet
- Optimizing the integration architecture for a major social networking news site
- Tuning the performance of software on a server appliance
- Analyzing performance issues for a major payroll vendor
- Designing messaging systems for optimal scalability and failover
- Migrating test systems to Amazon EC2 to reduce hardware needs and scale up load tests
On every project, Chariot architects begin by identifying specific performance and scalability metrics. We develop tests to clearly measure before and after progress toward these goals. With these tests and metrics, we can apply the right tools and drill down from system architecture to application architecture to the implementation of specific components, perhaps even as far as the JVM and OS/hardware platform. In this analysis, we'll set any prejudice aside and use real measurements to identify the biggest bottlenecks and break through them one at a time.
Sometimes it does come down to horizontal scalability, in which case we will ensure that the application is best architected to benefit from additional JVMs. In other cases, we might recommend changes to the core application or integration architecture, with specific numbers to back it up. We might also implement or optimize caching, whether in the persistence layer or at the Web server. Whether it ends there or we continue by tuning the JVM and garbage collector, we will get the performance you need out of the application. And to conclude every performance-tuning project, we leave the repeatable tests and measurements running in a continuous integration environment to monitor the progress going forward.
