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.

Google App Engine Management and Monitoring API

Google App Engine provides a very basic high-level system status page. It gives a quick on-off view of which of the GAE services are running and which are not. I am wondering if Google has any plans to provide a more API based and fine grained access to some of the monitoring and management data or have they purposefully left that gap for third party developers to build something against it. Of course it is fairly straightforward to write a quick-and-dirty monitoring system by running things inside GAE and doing real-time reporting (such as running monitoring GAE cron jobs with a API/UI interface). Google can do a much better job at it of course, given the fact that they have a lot more real & physical (vs. interpreted/derived) monitoring data that they already must be capturing. Maybe they just didn't get to publishing it yet.