3 ms·
I'm actually quite perplexed as to why the blog author chose to use the WSGIRef which is known to be one of the slowest of the bunch according to this much more
by wyuenho 14y ago
I'm actually quite perplexed as to why the blog author chose to use the WSGIRef which is known to be one of the slowest of the bunch according to this much more thorough benchmark:
http://nichol.as/benchmark-of-python-web-servers http://nichol.as/benchmark-of-python-web-servers
Even more perplexed, why wasn't the payload and the WSGI apps sources published?
- robert-zaremba 14y agoYour observation is good. Author should clarify this. But in his next articles he shows benchmark against other web frameworks, which shows more justified results
- fijal 14y agoThat doesn't really answer why use the slowest one with PyPy (and no, uWSGI does not work for PyPy, but a lot of stuff does)
- unbit 14y agouWSGI works with PyPY (Obviously with lot of limitations on the features). http://projects.unbit.it/uwsgi/wiki/PyPy http://projects.unbit.it/uwsgi/wiki/PyPy The problem is that for the vast majority of the webapps there is (still) no advantage. I only wanted to focus on that as i have invested days on (really complex for me) pypy sources, and i do not want people to ignore it ;)
- wyuenho 14y agoHis articles don't justify anything. I don't know what his payloads are or how he produced them in the apps. For all I know these 2 "benchmarks" are unreproducible. The author said he wanted to try science, there's nothing scientific about these 2 articles at all.