Not optimized for production use about aspen.py

[Changaco]

I've written a new dispatcher from scratch that is compatible with the current one (all the tests are passing) but is more optimized. It uses a cached dispatch tree instead of making system calls for every request.

[Changaco]

The new dispatcher is one order of magnitude faster than the old one. However I only measured the dispatching itself, whereas the percentages I mentioned in my first comment were for the entire request processing by Aspen+Pando.

[Changaco]

Observation of response times in HTTP logs suggests that when running on AWS with Apache's mod_wsgi the requests going through the dispatcher are more than 10 times slower than the requests that bypass it. (Update: Apache handles some requests itself, that's why they're 10x faster.) When running locally on my laptop with gunicorn the overhead of the dispatcher seems to be less than 20%.

The performance gain from optimizing the dispatcher will probably be closer to 10% than to 90%, but in any case it seems worth doing.

[chadwhitacre]

The performance gain from optimizing the dispatcher will probably be closer to 10% than to 90%, but in any case it seems worth doing.

I don't have a good link but iinm core Python's threshold for optimization is 10%: if it's not at least 10% faster then it's not worth the additional complexity.

[Changaco]

A profiling of Liberapay's code shows that the overhead of the old dispatcher is less than 2% when serving a dynamic page, but almost 22% when serving a small static file, so the new dispatcher should improve Aspen's performance by at least 20%.