Programming against a Performance Interface

We have been experimenting with the concept of coding against performance as part of a normal developer's activities versus doing it at the end of the product release cycle. Here are some things we are trying, maybe some of them are applicable to the general development community. I will explain them in the context of our development environment but they can be applied to almost all programming environments:

When a developer codes one or more operations that taken together constitute towards a user gesture, we want the developer to think about what server's response duration is acceptable for the given user gesture. User gesture can be something like, log in or creating a business object, search, and so on. This performance number is then recorded as a contract (Application Response Interface - an ARI as we like to call it) for that user gesture. The framework will then measure the actual response time as seen by the client and any time the contract for performance is broken, will trigger a performance exception. The performance exception report is then archived/sent to the instrumentation server with other relevant contextual information (user gesture, client properties, client location, and so on). The performance exception report can be further modified to do different things when running in development mode or production mode. In addition, it can be normalized to reflect such things as network latency between the client and server (which we also measure on a periodic basis - and gets sent to the instrumentation server as a latency report every few minutes).

We have other plans to correlate this to other server internal performance, but I will write about that in a later blog post.

We have implemented this using GWT on a Java based Google App Engine (GAE) application, but can be extended to any other programming environment.