From experience running benchmarks, I can tell you that in order to win them, you must have the full run of the servers, settings and the code. However, this is not the typical case in any large enterprise solution operating in the ‘real’ world.
How can you achieve inclusive buy in on performance from your team?
In order to make the fastest solutions in the world a performance team might have to fix problems ranging from algorithms, thread settings, network configurations, or the database implementation. Too often these problem areas operate in different silos of responsibility. This specialization is practical when there is depth required to resolve an issue that occurs within a single tower. However, some performance issues will take weeks to resolve across multiple teams.
How do you isolate a slowdown to an area that is not clearly defined?
Is the definition of performance for the tower a technical operation such as CPU utilization or Pages/sec?
The galvanizing performance component must be the business transaction.
Defining the Performance Requirements
At Orasi in the course of constructing our performance simulation, we first create a usage profile to capture the workload distribution. We layer this in with the volume and latency targets. These goals are more easily correlated to the business and their growth targets.
Do you perform a competitive analysis?
The latency and volume requirement gathering process is clear to understand, but too often it is difficult to capture due to the separation of responsibilities in the measurements and agreements.
How much clearer would the tasks be if each team had business transaction level targets to layer in with their uptime responsibilities?
Wouldn’t it be more logical to gauge faults in terms of slow or failed business transactions?
Optimization at the Business Transaction Level
Logically in order to speed these transactions up, you must follow it through the multiple tiers of the application itself. Modern businesses have generated improved value and cooperation within their IT solutions by connecting their towers together with web services and other EAI solutions. Now business transactions will flow across a complex web of queues and layers that add latency along the way.
How can you track a real transaction through your solution tiers?
Service Oriented Architecture
Micro-services and other ‘web’ enabled solutions have chosen the architectural design pattern to facilitate an agile delivery. These designs help larger teams work asynchronously, but they are by necessity, transport heavy. Plus if you don’t have a great way to monitor the activity the solution can easily become bogged down in communication design flaws. It is very easy to create a service that only returns one item at a time when the list contains a 1000 elements.
How can you find poorly designed algorithms when each service is very fast?
Monitoring and Measurement
Performance troubleshooting enterprise distributed applications can be slow and tedious without the right tools. Starting a year ago I started using AppDynamics and it has transformed the way we work. I can see the throughput and latency at every tier in real-time. I can set it up and map 90% of the solution in just a few hours. We can narrow down the problem to the correct tier to shorten the isolation problem without a complex marrying of different data. Development, operations, DBA, middleware, business owners and the Performance team are all connected in one workspace.
The performance world has changed because this new solution is so much faster to install, debug and analyze.
If you want to win the performance race, we can coach you to the next level.
