Duckhawk is there to help developers handle one crucial aspect in the long time evolution of a java library/application: performance.

Nowadays we have free tools to handle features and bugs, packaging, documentation and the like, all integrated in the continuous build process of an application. The topic of performance is not as well covered. This is understandable, whatever the application does must first be correct and accessible.

Tools like junitperf can be used to harness the familiar junit approach to set hard performance requirements, such as “operation x must not take more than y seconds” or “response time must not exceed z when the application is under load by n concurrent users”. Yet this approach fails to satisfy the needs of most open source projects, as well as some commercial ones:

• hard requirements are test host dependent (change the hardware where the test is run, you’ll have to adapt all all of the limits used as performance checks)

• an open source project has no hard performance requirements to meet

• hard requirements satisfaction does not tell anything about the actual performance evolution, developers won’t get notified that performance dropped 2 times if the hard requirement is still satisfied

On the other side of the spectrum we have utilities like JMeter, allowing a user to setup a multithreaded load test, run the tests and graph the results. Whilst this is possible, test setup is tedious, there is no build time automation, and programmatic control is hard.