Web performance in seven steps; Step 7: Share the responsibility for the whole chain

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.

Finger pointing does not help to solve the problem.
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.

Comments (4)

  1. Twitted by jborgers - Reply

    November 18, 2009 at 10:37 pm

    [...] This post was Twitted by jborgers [...]

  2. david Collier-Brown - Reply

    November 19, 2009 at 1:58 am

    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.


  3. AhsanShankar - Reply

    November 20, 2009 at 2:31 pm

    Nice article and thanks for sharing here

  4. mike prendergast - Reply

    January 10, 2010 at 2:47 pm

    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

Add a Comment