About performances

I recently focused on Dancer’s core with a single target in mind: optimization.
After having heavily refactored the Dancer::Route class, I started benchmarking Dancer.

To start with, I’ve created a set of test applications, in order to bench different kinds of application (from a hello world app to a huge one).

All these applications are available in this repository, if you like to see more precisely what I did.

The first test I did was to bench a “hello-world” application, with PSGI, Dancer 1.150 and the last version of the master branch.

hello.psgi .................... 1420 req/s
hello.dancer (1.150) .......... 1260 req/s
hello.dancer (github/master) .. 1320 req/s

You can see that Dancer “master” is about 100 req/s faster than 1.150, this is mainly thanks to Dancer::Route::Builder: Dancer now compiles all the routes defined by the application at startup time, and don’t spend time whenever a request is handled to do that job.

Moreover, thanks to SawyerX, Dancer now caches route resolution via Dancer::Route::Cache, and that increases response-time drastically when accessing an application with lots of routes.

Here is another bench that I did against an application with 676 routes handlers.

big.dancer (1.150, no cache, no route compiler) ...  110 req/s
big.dancer (GH, no cache, route compiler) .........  130 req/s
big.dancer (GH, cache, route compiler) ............ 1300 req/s

It appears clearly here that with a big number of route handlers, Dancer’s response-time decreases. I wanted to see more precisely how that occurs, and I run a bench in order to compare the response-time when varying the number of route hanlders.

As you can see on this graph, thanks to route caching, we now have a roughly constant response-time, no matter how many route handlers we have in the applicaiton.

These improvements will be shipped with the next CPAN version, either 1.151 or 1.160 if we have the time to add some new features as well.

Stay tuned.