Posted by Jeroen Borgers in the late evening: November 18th, 2009
Last time I blogged about performance tuning based on evidence, the tuning cycle and some best practices. This time I’ll blog about the last step of the seven steps: sharing the responsibility for the whole system chain.
When an incident happens in production, this usually means stress. A performance problem in production often leads to finger pointing. The DBA says that he has looked and nothing is wrong with his database. The network operator concludes the same thing about his network. The app server operator about his app server, the software developer about his source code and the back end operator about his back end. It is never them, it is the other.
Figure 1. Finger pointing does not help to solve the problem.
The application often gets thrown over the wall to the operation department. Responsibilities then hold only at one side of that wall. If software development, maintenance, testing and/or operation is outsourced to external parties this can lead to tricky situations. Before you know it, contracts and legal procedures are at play and cooperation is far away. Both parties stick to their position, costs will raise and precious time gets lost.
Finding out which part of the chain is responsible for the slowness can partly be solved with proper tools that monitor the whole chain and tools which are used from early on in the development process. But there is more to it than just tooling. Experience with and knowledge of tooling and technology is inevitable just as priority for the proper utilization of the tools. It is most important to prevent formation of separate kingdoms and finger pointing between them; and rather to operate together as a multi-disciplined performance team and share the responsibility for the whole chain.
We are almost there with this series 
Next time I’ll draw the final conclusions of these seven steps.
[...] This post was Twitted by jborgers [...]
One of my most pleasant projects ever was with a direct competitor, the usual locus of finger-pointing. We both expressed hopes that it was *our* problem, “because then we could just fix it”.
It took several long days of diagnostics, but it was a timing issue with my OS that broke an assumption in his application. If we hadn’t been prepared to share the problem, we wouldn’t have found the solution.
–dave
Nice article and thanks for sharing here
I agree whole heartedly, but i’d like to stress that performance should not just be an issue at, or near, production deployment.
There should be performance objectives set, and measured, during the whole code development cycle. In that way there are no suprises and also performance is seen as ajoint responsability across the whole support chain