In order to provide more reliable benchmark, I get rid of application server and network boundary. As a result I simulated a valid WSGI request and isolated calls just to the web framework alone. Also I found interesting to take a look at total number of calls and unique functions used by corresponding web framework.
The post has been updated: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Isolated benchmark source code is here: https://bitbucket.org/akorn/helloworld/src/tip/benchmark.py I should mention several web frameworks experience huge memory leaks in this benchmark. BONUS: added benchmark for python 3.3 (for the web frameworks that support it) and plain simple WSGI application (for contrast). Comments or suggestions are welcome. Thanks. Andriy Kornatskyy ---------------------------------------- > From: andriy.kornats...@live.com > To: ta...@ziade.org > Subject: RE: Fastest web framework > Date: Sat, 29 Sep 2012 12:18:32 +0300 > CC: python-list@python.org > > > Tarek, > > My response inline to your: > > > You are not getting my point. What happens to weezhy or XXX framework > > when you are running it in a given stack, under heavy load ? > > let me correct you, it is wheezy.web (not `weezhy`). > > Tell me your definition of web framework heavy load. If you have one, we > can try benchmark it. > > > There are many interactions that may impact the behavior of the stack - > > most of them are in the web server itself, but they can be things in the > > framework too, depending on the architectural choice. > > The reason I choose uWSGI is due to minimal possible impact that application > server may cause. Since this component `equally influence` productivity > of each framework it can be to some degree ignored. > > > And you will not know it with an hello world app. To put it more > > bluntly, your benchmark is going to join the big pile of hello worlds > > benchmarks that are completely meaningless. > > Can not agree. This is just simple thing. Simple things should run > fast, no doubt. If you can provide a better idea as to which framework > calls to put into benchmark, I will be happy extend the benchmark case. > > > If you want to prove that weezhy is faster than another py framework, > > because, I dunno, the number of function calls are smaller ? then you > > need to isolate this and > > do a different kind of bench. > > > > Have a look at http://plope.com/pyroptimization , it's a good example > > The numbers provided in that article are incorrect. They didn't match results > from the file they provide (result.txt in each framework dir) at the time > of writing. > > I have used that idea to re-run things (isolated benchmark; report with > total time, total number of calls and number of distinct functions used). > See here: > > https://bitbucket.org/akorn/helloworld/src/tip/benchmark.py > > I will update original post a bit later (to let you comment on this). > > > Same thing for the raw speed of your templating engine - isolation is > > required. > > Improved bigtable benchmark report by adding total number of calls and > number distinct functions used: > https://bitbucket.org/akorn/wheezy.template/src/tip/demos/bigtable/bigtable.py > > Original post not updated yet. > > > One good read: > > http://blog.ianbicking.org/2010/03/16/web-server-benchmarking-we-need/ > > Sounds not so bad. It points to some specific workloads. Any attempt to > prioritize > and/or practically implement them? > > Thanks. > > Andriy -- http://mail.python.org/mailman/listinfo/python-list
