Sawyer X

Recently I've spent more time with Dancer development, since it's such a fast, fun and flowing project. I've written Task::Dancer (after bugging a few people on #toolchain - thanks daxim!), Dancer::Template::Tiny and even patched Dancer::Template::Tenjin (and thanks to Ido for released it so quickly!).

Once thing I recently implemented in Dancer is Route Caching. Route Caching is a new term - at least for me - since I don't remember seeing it elsewhere (though I wouldn't be surprised if it's implemented in other frameworks).

When Dancer gets all the routes you want, it compiles them into regular expressions in a registry and then matches each request against the compiled routes, returning the first match. Route Caching allows to cache the path matches.

Theoretically if you have about 40 routes, and your 10 most wanted requests are in the lower set of the registry, Dancer would still have to go over the registry top to bottom, trying to match your request to a given compiled route. This is standard procedure and makes sense in every framework. However, this could be sped up.

Route Caching caches which request went to which compiled route and returns the compiled route instead of letting it go through the registry. As if it is saying "oh, this request? I know it, it goes to this specific route, no need to check the entire registry.

This, however, could be a sensitive issue, since many variable-based paths (/get/artist/:id) can increase the cache, taking more and more. You could set a size limit or a path limit, limiting either the size of the cache (KB, MB, GB) or the amount of paths it caches.

Once I add a feature to use the disk to read and write the cache, it would enable CGI-based applications to reap the benefits as well, without having persistence.

At first I thought this was pretty cool but as the evening set I was quite discouraged thinking maybe I should have worked on actually caching the results of pages (which Dancer will have soon enough). Today Alexis showed me results of benchmarks he did.

The benchmark test is available here, and these are the results he had:
<sukria> without caching: Requests per second: 73.19 [#/sec] (mean)
<sukria> with caching: Requests per second: 225.66 [#/sec] (mean)
<sukria> SCORE!
<sukria> ;)
<sawyer> oooo

This is not bad considering the caching isn't even on results, only on the matching of routes. Not too shabby. :)