Not optimized for production use
Changaco opened this issue · comments
When changes_reload is False: resources.get() should not touch the filesystem at all (no stat() call), and the dispatcher shouldn't touch the filesystem either (it should build a dispatch tree in RAM when the RequestProcessor is created).
Observation of response times in HTTP logs suggests that when running on AWS with Apache's (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%.mod_wsgi the requests going through the dispatcher are more than 10 times slower than the requests that bypass it.
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'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.
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.
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.
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%.