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.

Filed under Java, Performance, Process, Tools | 4 Comments »