Path: csiph.com!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!feeds.phibee-telecom.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
From: Andriy Kornatskyy <andriy.kornatskyy@live.com>
To: Tarek Ziade <tarek@ziade.org>
Subject: RE: Fastest web framework
Date: Tue, 2 Oct 2012 16:17:40 +0300
Importance: Normal
In-Reply-To: <DUB117-W30563FACD45427AB23024091810@phx.gbl>
References: <DUB117-W80EE2285B5E415AA14B5B9919F0@phx.gbl>, , <50604907.6060405@ziade.org>, <DUB117-W20C405466BE1C21E8F0FEE919D0@phx.gbl>, , <5062C603.90905@ziade.org>, <DUB117-W1187300EA6CC66C00907F92919C0@phx.gbl>, , <5062CDC6.40703@ziade.org>, <DUB117-W30563FACD45427AB23024091810@phx.gbl>
Content-Type: text/plain; charset="windows-1251"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "python-list@python.org" <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1723.1349183929.27098.python-list@python.org>
Lines: 110
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:30632


In order to provide more reliable benchmark=2C I get rid of application ser=
ver 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 correspo=
nding 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 thi=
s=A0benchmark.

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@live.com
> To: tarek@ziade.org
> Subject: RE: Fastest web framework
> Date: Sat=2C 29 Sep 2012 12:18:32 +0300
> CC: python-list@python.org
>
>
> Tarek=2C
>
> 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=2C under heavy load ?
>
> let me correct you=2C it is wheezy.web (not `weezhy`).
>
> Tell me your definition of web framework heavy load. If you have one=2C w=
e
> 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=2C but they can be things in =
the
> > framework too=2C depending on the architectural choice.
>
> The reason I choose uWSGI is due to minimal possible impact that applicat=
ion
> 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=2C 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=2C no doubt. If you can provide a better idea as to which framework
> calls to put into benchmark=2C I will be happy extend the benchmark case.
>
> > If you want to prove that weezhy is faster than another py framework=2C
> > because=2C I dunno=2C the number of function calls are smaller ? then y=
ou
> > need to isolate this and
> > do a different kind of bench.
> >
> > Have a look at http://plope.com/pyroptimization =2C it's a good example
>
> The numbers provided in that article are incorrect. They didn't match res=
ults
> 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=3B report with
> total time=2C 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/bigtab=
le.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 p=
rioritize
> and/or practically implement them?
>
> Thanks.
>
> Andriy
 		 	   		  =