Hi and welcome to DeveloperLife, written by Nadav Azaria and Roi Gamliel. In this blog we write about our own experience in software development, trying to share our knowledge following new technologies we adopt or problems we face.

Tuesday, April 10, 2012

Performance Parameters - What should I expose?

This post begins with a short poll. Did you ever let your end-user
determine your application's thread pool size? Well if you didn't then you are
a better man then us, because we did and we were wrong doing so. Thread pool
size is just an example to a variety of performance parameters we
tend to publish as configuration. We don't mean to but do so at some point of
our application life cycle.

Like any good fairy tale at the beginning everyone are happy with
our new application. Then slowly but steady complaints start coming stating it
is too slow. To make it faster we use every trick we now. We start
optimizing SQL's, parallel what we can, use threads and refactor the code to be
more efficient. Everyone's happy? Not Yet! Now we get complaints
that although the job is done fast, the application takes too many
resources. "No problem", we say and immediately publish every performance
parameter we have in the code as configuration. That includes stuff like batch
size, poll interval, sleep time and naturally thread pool size.

This turns out to be a bad idea. It is a bad idea because the user
has no way of knowing which values are adequate. Moreover the values probably
depend on the hardware used, which as we know changes rapidly. It is a bad idea
because it uncovers implementation details. But it is a bad
idea mostly because it is not part of the user domain language.

Performance parameters should be handled just like any other
feature in the software. One should think of the user story behind it and
specify configuration accordingly. Some time it is only a terminology
change. Instead of using "thread pool size" you
use "number of client served simultaneously". Sometimes
the mapping from the configuration parameter to an inner parameter will involve
some computation and heuristics. So you might configure "Number of
items processed per minute" which will be translated to "batch
size", "poll interval" and so on....

So keep in mind. Performance parameters are not second-class
citizens. It should be specified with the same abstraction layer as the rest of
the software. It should hide any inner implementation details and if possible
it should be hardware independent.