Fastest web framework

[Andriy Kornatskyy]

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.kornatskyy at live.com
> To: tarek at ziade.org
> Subject: RE: Fastest web framework
> Date: Sat, 29 Sep 2012 12:18:32 +0300
> CC: python-list at 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