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.

Making GWT UncaughtExceptionHandler send problem reports to server

If you are using GWT to write any level of real world application, you will most likely implement the com.google.gwt.core.client.GWT.UncaughtExceptionHandler. This is setup via the API provided via com.google.gwt.core.client.GWT (setUncaughtExceptionHandler()).

We have added some additional error reporting code in the exception handler, that will report the exception to the server. Along with the exception trace we are also sending client context and operation state information (and of course user-agent information is paired with that on the server). This entire set of information is logged in to the database for analysis. Given the differences in cross-browser implementation of some of these technologies, we hope to be able to make the quality of code better via this reporting mechanism. We simply don't have the bandwidth to test every user action on every browser (that of course is the very reason we use GWT).

We will report on our findings after letting this code run for a few weeks.