Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Fastest web framework
778 views
Skip to first unread message
Andriy Kornatskyy
Sep 23, 2012, 5:19:16 AM9/23/12
to pytho...@python.org
I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
Comments or suggestions are welcome.
Thanks.
Andriy Kornatskyy
Roy Smith
Sep 23, 2012, 10:02:28 AM9/23/12
to
In article <mailman.1110.1348392...@python.org>,
That's a nice comparison, thanks for posting it.
One thing that's worth pointing out, however, is that in a real world
application, as long as you're using something halfway decent, the speed
of the framework is probably not going to matter at all. It's much more
likely that database throughput will be the dominating factor.
One thing that's worth pointing out, however, is that in a real world
application, as long as you're using something halfway decent, the speed
of the framework is probably not going to matter at all. It's much more
likely that database throughput will be the dominating factor.
Stefan Behnel
Sep 23, 2012, 11:50:20 AM9/23/12
to pytho...@python.org
Roy Smith, 23.09.2012 16:02:
own engine) a bit less interesting. Worth keeping this in mind:
http://www.codeirony.com/?p=9
Stefan
> Andriy Kornatskyy wrote:
>> I have run recently a benchmark of a trivial 'hello world' application for
>> various python web frameworks (bottle,�django, flask, pyramid, web.py,
>> wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find
>> it interesting:
>>
>> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>>
>> Comments or suggestions are welcome.
>
> That's a nice comparison, thanks for posting it.
>
> One thing that's worth pointing out, however, is that in a real world
> application, as long as you're using something halfway decent, the speed
> of the framework is probably not going to matter at all. It's much more
> likely that database throughput will be the dominating factor.
Yes, that makes the comparison (which may or may not be biased towards his
>> I have run recently a benchmark of a trivial 'hello world' application for
>> various python web frameworks (bottle,�django, flask, pyramid, web.py,
>> wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find
>> it interesting:
>>
>> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>>
>> Comments or suggestions are welcome.
>
> That's a nice comparison, thanks for posting it.
>
> One thing that's worth pointing out, however, is that in a real world
> application, as long as you're using something halfway decent, the speed
> of the framework is probably not going to matter at all. It's much more
> likely that database throughput will be the dominating factor.
own engine) a bit less interesting. Worth keeping this in mind:
http://www.codeirony.com/?p=9
Stefan
Mark Lawrence
Sep 23, 2012, 1:20:03 PM9/23/12
to pytho...@python.org
On 23/09/2012 16:50, Stefan Behnel wrote:
> Roy Smith, 23.09.2012 16:02:
> Roy Smith, 23.09.2012 16:02:
>> Andriy Kornatskyy wrote:
>>> I have run recently a benchmark of a trivial 'hello world' application for
>>> various python web frameworks (bottle,�django, flask, pyramid, web.py,
>>> wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find
>>> it interesting:
>>>
>>> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>>>
>>> Comments or suggestions are welcome.
>>
>> That's a nice comparison, thanks for posting it.
>>
>> One thing that's worth pointing out, however, is that in a real world
>> application, as long as you're using something halfway decent, the speed
>> of the framework is probably not going to matter at all. It's much more
>> likely that database throughput will be the dominating factor.
>
>>> I have run recently a benchmark of a trivial 'hello world' application for
>>> various python web frameworks (bottle,�django, flask, pyramid, web.py,
>>> wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find
>>> it interesting:
>>>
>>> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>>>
>>> Comments or suggestions are welcome.
>>
>> That's a nice comparison, thanks for posting it.
>>
>> One thing that's worth pointing out, however, is that in a real world
>> application, as long as you're using something halfway decent, the speed
>> of the framework is probably not going to matter at all. It's much more
>> likely that database throughput will be the dominating factor.
>
> Yes, that makes the comparison (which may or may not be biased towards his
> own engine) a bit less interesting. Worth keeping this in mind:
>
> http://www.codeirony.com/?p=9
>
> Stefan
>
>
I'd like to say thanks for the link but unfortunately for me, but good
> own engine) a bit less interesting. Worth keeping this in mind:
>
> http://www.codeirony.com/?p=9
>
> Stefan
>
>
news for you (plural), is that I've bust a gut laughing out loud, so I
won't :)
Oh alright then thanks for the link.
--
Cheers.
Mark Lawrence.
Andriy Kornatskyy
Sep 23, 2012, 1:42:47 PM9/23/12
to pytho...@python.org
If we take a look at web application we can split it into at least two parts, one that renders things out and the other one that does data extraction, e.g. from database (this is what you are pointing at).
If you made a first call to database you get your list and can easily cache it. The next call IS without impact that database call may cause... but you still keep serving pages out...
Thanks.
Andriy
----------------------------------------
From: r...@panix.com
Subject: Re: Fastest web framework
Date: Sun, 23 Sep 2012 10:02:28 -0400
To: pytho...@python.org
http://mail.python.org/mailman/listinfo/python-list
Stefan Behnel
Sep 23, 2012, 1:48:12 PM9/23/12
to pytho...@python.org
Andriy Kornatskyy, 23.09.2012 19:42:
first place but static pages, would you?
Stefan
> If we take a look at web application we can split it into at least two
> parts, one that renders things out and the other one that does data
> extraction, e.g. from database (this is what you are pointing at).
>
> If you made a first call to database you get your list and can easily
> cache it. The next call IS without impact that database call may
> cause... but you still keep serving pages out...
Well, if it was really that easy, you wouldn't be using a database in the
> parts, one that renders things out and the other one that does data
> extraction, e.g. from database (this is what you are pointing at).
>
> If you made a first call to database you get your list and can easily
> cache it. The next call IS without impact that database call may
> cause... but you still keep serving pages out...
first place but static pages, would you?
Stefan
Andriy Kornatskyy
Sep 23, 2012, 1:57:55 PM9/23/12
to pytho...@python.org
Few facts that doesn't make it less interesting:
(1) the test source code available
(2) the test itself is pretty famous
(3) you can re-run it
(4) or even better supply own that in your believe is 100% relevant
Not every project has problem with database performance. Some use caching... and pretty happy. In my case I have got 2x boost of web application performance just by switching to wheezy.template, that simple.
Thanks.
Andriy
----------------------------------------
> To: pytho...@python.org
> From: stef...@behnel.de
> Subject: Re: Fastest web framework
> Date: Sun, 23 Sep 2012 17:50:20 +0200
>
> Roy Smith, 23.09.2012 16:02:
> Roy Smith, 23.09.2012 16:02:
> > Andriy Kornatskyy wrote:
> >> I have run recently a benchmark of a trivial 'hello world' application for
> >> various python web frameworks (bottle,�django, flask, pyramid, web.py,
> >> wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find
> >> it interesting:
> >>
> >> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >>
> >> Comments or suggestions are welcome.
> >
> > That's a nice comparison, thanks for posting it.
> >
> > One thing that's worth pointing out, however, is that in a real world
> > application, as long as you're using something halfway decent, the speed
> > of the framework is probably not going to matter at all. It's much more
> > likely that database throughput will be the dominating factor.
>
> >> I have run recently a benchmark of a trivial 'hello world' application for
> >> various python web frameworks (bottle,�django, flask, pyramid, web.py,
> >> wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find
> >> it interesting:
> >>
> >> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >>
> >> Comments or suggestions are welcome.
> >
> > That's a nice comparison, thanks for posting it.
> >
> > One thing that's worth pointing out, however, is that in a real world
> > application, as long as you're using something halfway decent, the speed
> > of the framework is probably not going to matter at all. It's much more
> > likely that database throughput will be the dominating factor.
>
> Yes, that makes the comparison (which may or may not be biased towards his
> own engine) a bit less interesting. Worth keeping this in mind:
>
> http://www.codeirony.com/?p=9
>
> Stefan
>
>
> --
> own engine) a bit less interesting. Worth keeping this in mind:
>
> http://www.codeirony.com/?p=9
>
> Stefan
>
>
> http://mail.python.org/mailman/listinfo/python-list
Andriy Kornatskyy
Sep 23, 2012, 2:15:44 PM9/23/12
to pytho...@python.org
Good to know you are in a good humor today. You will be surprised... far not all share your point of view. ;-)
Few links for you to stop laughing that loud:
http://packages.python.org/wheezy.http/userguide.html#content-cache
http://packages.python.org/wheezy.caching/userguide.html#cachedependency
Andriy
----------------------------------------
> To: pytho...@python.org
> From: bream...@yahoo.co.uk
> Subject: Re: Fastest web framework
> Date: Sun, 23 Sep 2012 18:20:03 +0100
>
> On 23/09/2012 16:50, Stefan Behnel wrote:
> On 23/09/2012 16:50, Stefan Behnel wrote:
> > Roy Smith, 23.09.2012 16:02:
> >> Andriy Kornatskyy wrote:
> >>> I have run recently a benchmark of a trivial 'hello world' application for
> >>> various python web frameworks (bottle,�django, flask, pyramid, web.py,
> >>> wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find
> >>> it interesting:
> >>>
> >>> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >>>
> >>> Comments or suggestions are welcome.
> >>
> >> That's a nice comparison, thanks for posting it.
> >>
> >> One thing that's worth pointing out, however, is that in a real world
> >> application, as long as you're using something halfway decent, the speed
> >> of the framework is probably not going to matter at all. It's much more
> >> likely that database throughput will be the dominating factor.
> >
> >>> I have run recently a benchmark of a trivial 'hello world' application for
> >>> various python web frameworks (bottle,�django, flask, pyramid, web.py,
> >>> wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find
> >>> it interesting:
> >>>
> >>> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >>>
> >>> Comments or suggestions are welcome.
> >>
> >> That's a nice comparison, thanks for posting it.
> >>
> >> One thing that's worth pointing out, however, is that in a real world
> >> application, as long as you're using something halfway decent, the speed
> >> of the framework is probably not going to matter at all. It's much more
> >> likely that database throughput will be the dominating factor.
> >
> > Yes, that makes the comparison (which may or may not be biased towards his
> > own engine) a bit less interesting. Worth keeping this in mind:
> >
> > http://www.codeirony.com/?p=9
> >
> > Stefan
> >
> >
>
> > own engine) a bit less interesting. Worth keeping this in mind:
> >
> > http://www.codeirony.com/?p=9
> >
> > Stefan
> >
> >
>
> I'd like to say thanks for the link but unfortunately for me, but good
> news for you (plural), is that I've bust a gut laughing out loud, so I
> won't :)
>
> Oh alright then thanks for the link.
>
> --
> Cheers.
>
> Mark Lawrence.
>
> --
> news for you (plural), is that I've bust a gut laughing out loud, so I
> won't :)
>
> Oh alright then thanks for the link.
>
> --
> Cheers.
>
> Mark Lawrence.
>
> http://mail.python.org/mailman/listinfo/python-list
Andriy Kornatskyy
Sep 23, 2012, 2:16:23 PM9/23/12
to pytho...@python.org
Good to know you are in a good humor today. You will be surprised... far not all share your point of view. ;-)
Few links for you to stop laughing that loud:
http://packages.python.org/wheezy.http/userguide.html#content-cache
http://packages.python.org/wheezy.caching/userguide.html#cachedependency
Andriy
----------------------------------------
> To: pytho...@python.org
> From: bream...@yahoo.co.uk
> Subject: Re: Fastest web framework
> Date: Sun, 23 Sep 2012 18:20:03 +0100
>
> On 23/09/2012 16:50, Stefan Behnel wrote:
> > Roy Smith, 23.09.2012 16:02:
> >> Andriy Kornatskyy wrote:
> >>> I have run recently a benchmark of a trivial 'hello world' application for
> >>> various python web frameworks (bottle,�django, flask, pyramid, web.py,
> >>> wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find
> >>> it interesting:
> >>>
> >>> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >>>
> >>> Comments or suggestions are welcome.
> >>
> >> That's a nice comparison, thanks for posting it.
> >>
> >> One thing that's worth pointing out, however, is that in a real world
> >> application, as long as you're using something halfway decent, the speed
> >> of the framework is probably not going to matter at all. It's much more
> >> likely that database throughput will be the dominating factor.
> >
> >>> I have run recently a benchmark of a trivial 'hello world' application for
> >>> various python web frameworks (bottle,�django, flask, pyramid, web.py,
> >>> wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find
> >>> it interesting:
> >>>
> >>> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >>>
> >>> Comments or suggestions are welcome.
> >>
> >> That's a nice comparison, thanks for posting it.
> >>
> >> One thing that's worth pointing out, however, is that in a real world
> >> application, as long as you're using something halfway decent, the speed
> >> of the framework is probably not going to matter at all. It's much more
> >> likely that database throughput will be the dominating factor.
> >
Andriy Kornatskyy
Sep 23, 2012, 2:17:20 PM9/23/12
to pytho...@python.org
Good to know you are in a good humor today. You will be surprised... far not all share your point of view. ;-)
Few links for you to stop laughing that loud:
http://packages.python.org/wheezy.http/userguide.html#content-cache
http://packages.python.org/wheezy.caching/userguide.html#cachedependency
Andriy
----------------------------------------
> To: pytho...@python.org
> From: bream...@yahoo.co.uk
> Subject: Re: Fastest web framework
> Date: Sun, 23 Sep 2012 18:20:03 +0100
>
> On 23/09/2012 16:50, Stefan Behnel wrote:
> > Roy Smith, 23.09.2012 16:02:
> >> Andriy Kornatskyy wrote:
> >>> I have run recently a benchmark of a trivial 'hello world' application for
> >>> various python web frameworks (bottle,�django, flask, pyramid, web.py,
> >>> wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find
> >>> it interesting:
> >>>
> >>> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >>>
> >>> Comments or suggestions are welcome.
> >>
> >> That's a nice comparison, thanks for posting it.
> >>
> >> One thing that's worth pointing out, however, is that in a real world
> >> application, as long as you're using something halfway decent, the speed
> >> of the framework is probably not going to matter at all. It's much more
> >> likely that database throughput will be the dominating factor.
> >
> >>> I have run recently a benchmark of a trivial 'hello world' application for
> >>> various python web frameworks (bottle,�django, flask, pyramid, web.py,
> >>> wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find
> >>> it interesting:
> >>>
> >>> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >>>
> >>> Comments or suggestions are welcome.
> >>
> >> That's a nice comparison, thanks for posting it.
> >>
> >> One thing that's worth pointing out, however, is that in a real world
> >> application, as long as you're using something halfway decent, the speed
> >> of the framework is probably not going to matter at all. It's much more
> >> likely that database throughput will be the dominating factor.
> >
Andriy Kornatskyy
Sep 23, 2012, 2:41:10 PM9/23/12
to stef...@behnel.de, pytho...@python.org
The problem is that easy if you have a complete control over what you are caching.
Complete control over cache may look a challenging task however with use of cache dependency you can lower it significantly. Take a look here:
http://packages.python.org/wheezy.caching/userguide.html#cachedependency
If you have a willing to go even further consider take a look at content caching:
http://packages.python.org/wheezy.http/userguide.html#content-cache
Serving static page out of your data is not that impossible... there are still exceptions, of cause.
Thanks.
Andriy
----------------------------------------
> To: pytho...@python.org
> From: stef...@behnel.de
> Subject: Re: Fastest web framework
> Date: Sun, Sep 2 :::::: +0<<<
>
> Andriy Kornatskyy, ......2 ::::::
> http://mail.python.org/mailman/listinfo/python-list
Dwight Hutto
Sep 23, 2012, 3:28:35 PM9/23/12
to Andriy Kornatskyy, pytho...@python.org
On Sun, Sep 23, 2012 at 5:19 AM, Andriy Kornatskyy
<andriy.k...@live.com> wrote:
>
> I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9
There are other considerations that must be made when running a 'hello world'.
<andriy.k...@live.com> wrote:
>
> I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9
-It is a basic string, but no numerical benchmarks.
-You've overlooked the fact that different OS's have other processes
at work, which need to be looked at
-and a function which performed several tasks(a string, and
numerical), and then returned the result on seveal operating systems,
with non-essential processes turned off
-etc
--
Best Regards,
David Hutto
CEO: http://www.hitwebdevelopment.com
Andriy Kornatskyy
Sep 23, 2012, 3:48:38 PM9/23/12
to dwight...@gmail.com, pytho...@python.org
> On Sun, Sep 23, 2012 at 5:19 AM, Andriy Kornatskyy
> <andriy.k...@live.com> wrote:
> >
> > I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9
>
> There are other considerations that must be made when running a 'hello world'.
>
> -It is a basic string, but no numerical benchmarks.
> -You've overlooked the fact that different OS's have other processes
> at work, which need to be looked at
> -and a function which performed several tasks(a string, and
> numerical), and then returned the result on seveal operating systems,
> with non-essential processes turned off
Hope I understood you correctly.
Thanks.
Andriy
Dwight Hutto
Sep 23, 2012, 4:16:15 PM9/23/12
to Andriy Kornatskyy, pytho...@python.org
> Hope I understood you correctly.
>
Well, lets break down timing something in a more scientific method
>
approach through questioning.
What's your processor speed?
What is the constant temperature of the internals of your system?
What OS, and version?
What other processes are running?
There's a scientific method to what you're benchmarking. There have to
be constants, and variables to benchmark with.
These will of course vary with other methods of approach with the same code.
Alex Clark
Sep 23, 2012, 5:25:20 PM9/23/12
to pytho...@python.org
On 2012-09-23 09:19:16 +0000, Andriy Kornatskyy said:
>
> I have run recently a benchmark of a trivial 'hello world' application
> for various python web frameworks (bottle, django, flask, pyramid,
>
> I have run recently a benchmark of a trivial 'hello world' application
> for various python web frameworks (bottle, django, flask, pyramid,
> web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9...
> you might find it interesting:
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
> Comments or suggestions are welcome.
Are you on Python Planet? If not, you might want to syndicate your blog
> you might find it interesting:
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
> Comments or suggestions are welcome.
there to reach more of the Python web framework crowd.
>
> Thanks.
>
> Andriy Kornatskyy
>
--
Alex Clark · http://pythonpackages.com
Andriy Kornatskyy
Sep 24, 2012, 2:34:48 AM9/24/12
to dwight...@gmail.com, pytho...@python.org
David,
Thank you for your comments. Please see my response inline to your questions.
> Well, lets break down timing something in a more scientific method
> approach through questioning.
>
> What's your processor speed?
Client: Intel Core 2 Quad CPU Q6600 @ 2.40GHz × 4
Server: Intel Xeon CPU X3430 @ 2.40GHz x 4
LAN 1 Gb
> What is the constant temperature of the internals of your system?
> What OS, and version?
Server: Debian Testing, Kernel 3.2.0-3-amd64, Python 2.7.3, uwsgi 1.2.6
Client: Debian Testing, Kernel 3.2.0-3-686-pae
> What other processes are running?
Thanks.
Andriy Kornatskyy
----------------------------------------
> Date: Sun, 3 Sep 012 6::6::5 -400<
> Subject: Re: Fastest web framework
> From: dwight...@gmail.com
> To: andriy.k...@live.com
> CC: pytho...@python.org
Andriy Kornatskyy
Sep 24, 2012, 2:53:58 AM9/24/12
to acl...@aclark.net, pytho...@python.org
Alex,
> Are you on Python Planet? If not, you might want to syndicate your blog
> there to reach more of the Python web framework crowd.
http://feeds.feedburner.com/MindReference
> From: acl...@aclark.net
> Subject: Re: Fastest web framework
> Date: Sun, 23 Sep 2012 17:25:20 -0400
> http://mail.python.org/mailman/listinfo/python-list
Andriy Kornatskyy
Sep 24, 2012, 4:42:47 AM9/24/12
to alec.t...@gmail.com, pytho...@python.org
Accepted.
________________________________
> Date: Mon, 24 Sep 2012 17:36:25 +1000
> Subject: Re: Fastest web framework
> From: alec.t...@gmail.com
> To: andriy.k...@live.com
> CC: pytho...@python.org
>
> Can you throw in web2py?
>
> Thanks
>
> On Sun, Sep 23, 2012 at 7:19 PM, Andriy Kornatskyy
> <andriy.k...@live.com<mailto:andriy.k...@live.com>> wrote:
>
> I have run recently a benchmark of a trivial 'hello world' application
> for various python web frameworks (bottle, django, flask, pyramid,
> web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9...
> you might find it interesting:
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
> Comments or suggestions are welcome.
>
> Thanks.
> On Sun, Sep 23, 2012 at 7:19 PM, Andriy Kornatskyy
> <andriy.k...@live.com<mailto:andriy.k...@live.com>> wrote:
>
> I have run recently a benchmark of a trivial 'hello world' application
> for various python web frameworks (bottle, django, flask, pyramid,
> web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9...
> you might find it interesting:
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
> Comments or suggestions are welcome.
>
>
> Andriy Kornatskyy
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Tarek Ziadé
Sep 24, 2012, 7:50:31 AM9/24/12
to pytho...@python.org
On 9/23/12 11:19 AM, Andriy Kornatskyy wrote:
> I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
> Comments or suggestions are welcome.
>
> Thanks.
>
> Andriy Kornatskyy
>
I would try this with a web app that does more than 'Hello World'
> I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
> Comments or suggestions are welcome.
>
> Thanks.
>
> Andriy Kornatskyy
>
You may argue that you're just trying the server stack, but that's not
realistic because you don't really measure how the server behaves with a
real app.
Have a look at
https://github.com/mozilla-services/chaussette/blob/master/chaussette/util.py#L188
(setup_bench and teardow_bench have to be run on startup and tear down
of the server)
I would be curious to see how things goes then
Cheers
Tarek
Albert Hopkins
Sep 24, 2012, 3:42:00 PM9/24/12
to pytho...@python.org
On Sun, 2012-09-23 at 12:19 +0300, Andriy Kornatskyy wrote:
> I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
> Comments or suggestions are welcome.
>
The thing I don't like about these benchmarks is.. they tell you which
> I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
> Comments or suggestions are welcome.
>
framework is best for writing a trivial 'hello world' application. But
no one writes trivial 'hello world' applications. A
framework/programming language/software package/what-have-you. Can be
really fast for trivial stuff, but perform much less favorably when
performing "real-world" tasks. It's kind of the same argument that's
used when people say X computer boots faster than Y computer. That's
nice and all, but I spend much more of my time *using* my computer than
*booting* it, so it doesn't give me a good picture of how the computers
perform. This is why most "good" benchmarks run a series various tests
based on real-world use cases.
-a
Andriy Kornatskyy
Sep 24, 2012, 4:17:19 PM9/24/12
to mar...@letterboxes.org, pytho...@python.org
Try to see 'Hello World' benchmark as an answer to the question how effective is the framework inside...
If computer X boots faster than Y, it means it is more effective in this particular area.
If a sportsman runs a distance 1 second faster than other, he got a medal (it is not quite adequate to say if I load sportsman with 50 kilo bag he will not run that fast... just try split the concerns).
Thanks.
Andriy
----------------------------------------
> Subject: Re: Fastest web framework
> From: mar...@letterboxes.org
> To: pytho...@python.org
> Date: Mon, 24 Sep 2012 15:42:00 -0400
> http://mail.python.org/mailman/listinfo/python-list
Andriy Kornatskyy
Sep 25, 2012, 6:52:25 AM9/25/12
to pytho...@python.org
The post has been updated with two more frameworks (per community request): tornado and web2py.
Comments or suggestions are welcome.
Andriy Kornatskyy
----------------------------------------
> From: andriy.k...@live.com
> To: pytho...@python.org
> Subject: Fastest web framework
> Date: Sun, 23 Sep 2012 12:19:16 +0300
>
>
> I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
> Comments or suggestions are welcome.
>
>
> I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
> Comments or suggestions are welcome.
>
Andriy Kornatskyy
Sep 25, 2012, 7:01:19 AM9/25/12
to alec.t...@gmail.com, pytho...@python.org
Alec
While performing benchmark for web2py I noticed a memory leak. It constantly grows and never release it...
Thanks.
Andriy Kornatskyy
________________________________
> Date: Mon, 24 Sep 2012 17:36:25 +1000
> Subject: Re: Fastest web framework
> From: alec.t...@gmail.com
> To: andriy.k...@live.com
> CC: pytho...@python.org
>
> Can you throw in web2py?
>
> Thanks
>
> On Sun, Sep 23, 2012 at 7:19 PM, Andriy Kornatskyy
> <andriy.k...@live.com<mailto:andriy.k...@live.com>> wrote:
>
> To: andriy.k...@live.com
> CC: pytho...@python.org
>
> Can you throw in web2py?
>
> Thanks
>
> On Sun, Sep 23, 2012 at 7:19 PM, Andriy Kornatskyy
> <andriy.k...@live.com<mailto:andriy.k...@live.com>> wrote:
>
Andriy Kornatskyy
Sep 25, 2012, 9:21:07 AM9/25/12
to ta...@ziade.org, pytho...@python.org
Tarek,
With all respect, running benchmark on something that has sleeps, etc is pretty far from real world use case. So I went a little bit different way.
Here is a live demo (a semi real world web application) that comes with wheezy.web framework as a template:
http://wheezy.pythonanywhere.com/
I have implemented it in a way that it uses one web framework (wheezy.web) and various template engines (jinja2, mako, tenjin, wheezy.template and wheezy.template with preprocessor)... Please see the following post under `Real World Example` section:
http://mindref.blogspot.com/2012/07/python-fastest-template.html
Source code here:
https://bitbucket.org/akorn/wheezy.web/src/tip/demos/template
The real world example shows the difference between template engines implementing the same things. The same applies to web frameworks (more or less depending on your choice).
Thanks.
Andriy
----------------------------------------
> Date: Mon, 24 Sep 2012 13:50:31 +0200
> From: ta...@ziade.org
> To: pytho...@python.org
> Subject: Re: Fastest web framework
>
>
> On 9/23/12 11:19 AM, Andriy Kornatskyy wrote:
> > I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
> >
> > http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >
> > Comments or suggestions are welcome.
> >
> > Thanks.
> >
> > Andriy Kornatskyy
> >
> > I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
> >
> > http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >
> > Comments or suggestions are welcome.
> >
> > Thanks.
> >
> > Andriy Kornatskyy
> >
> I would try this with a web app that does more than 'Hello World'
>
> You may argue that you're just trying the server stack, but that's not
> realistic because you don't really measure how the server behaves with a
> real app.
>
> Have a look at
> https://github.com/mozilla-services/chaussette/blob/master/chaussette/util.py#L188
>
> (setup_bench and teardow_bench have to be run on startup and tear down
> of the server)
>
> I would be curious to see how things goes then
>
> Cheers
> Tarek
> --
>
> You may argue that you're just trying the server stack, but that's not
> realistic because you don't really measure how the server behaves with a
> real app.
>
> Have a look at
> https://github.com/mozilla-services/chaussette/blob/master/chaussette/util.py#L188
>
> (setup_bench and teardow_bench have to be run on startup and tear down
> of the server)
>
> I would be curious to see how things goes then
>
> Cheers
> Tarek
> http://mail.python.org/mailman/listinfo/python-list
Tarek Ziadé
Sep 26, 2012, 5:08:19 AM9/26/12
to Andriy Kornatskyy, pytho...@python.org
On 9/25/12 3:21 PM, Andriy Kornatskyy wrote:
> Tarek,
>
> With all respect, running benchmark on something that has sleeps, etc is pretty far from real world use case. So I went a little bit different way.
That's not a good summary of what the function does. It does not just
> Tarek,
>
> With all respect, running benchmark on something that has sleeps, etc is pretty far from real world use case. So I went a little bit different way.
sleep. It does some I/O and CPU bound tasks. The sleep is here to
simulate a blocking I/O call, besides the DB calls.
The whole function tries to simulate a real application, unlike printing
'Hello World' - to put the stack under realistic conditions.
The multiplication is cached by the processor, but will still push some
CPU work on every call.
>
> Here is a live demo (a semi real world web application) that comes with wheezy.web framework as a template:
>
> http://wheezy.pythonanywhere.com/
>
> I have implemented it in a way that it uses one web framework (wheezy.web) and various template engines (jinja2, mako, tenjin, wheezy.template and wheezy.template with preprocessor)... Please see the following post under `Real World Example` section:
>
> http://mindref.blogspot.com/2012/07/python-fastest-template.html
>
> Source code here:
>
> https://bitbucket.org/akorn/wheezy.web/src/tip/demos/template
>
> The real world example shows the difference between template engines implementing the same things. The same applies to web frameworks (more or less depending on your choice).
>
> Thanks.
engines, but this is still not what I had in mind.
What I had in mind was to try each one of the framework with an
application that does things, and see how the whole stack reacts on high
load.
But I guess we have different goals - wheezy seems really fast, congrats.
Cheers
Tarek
Andriy Kornatskyy
Sep 26, 2012, 5:26:50 AM9/26/12
to ta...@ziade.org, pytho...@python.org
Tarek,
Thank you for the response back. Yes, your idea is pretty clear to me. The point is that higher workload you put in your application business logic, repository, backend, whatever... less you will see in final results comparison. This is obvious and we, as technical people, very well understand this (somebody even laugh).
The reality is that not all web applications do heavy CPU computations and/or experience IO delays (due to response from database running a query over table that has no index, let say), some use caches, some split jobs to be run in background, some parallel them... I have to state that simple things must perform really fast to give more room for one that are not so. That in turn makes your infrastructure more effective. Some prefer to add a box, some see that a likely to be a problem further it goes. The good thing - you have a choice, you are not locked, and as result you are responsible for the effectiveness of the system you build today and definitely next one.
Take care.
Andriy
----------------------------------------
> Date: Wed, 26 Sep 2012 11:08:19 +0200
> From: ta...@ziade.org
> To: andriy.k...@live.com
> CC: pytho...@python.org
Tarek Ziadé
Sep 26, 2012, 5:41:26 AM9/26/12
to Andriy Kornatskyy, pytho...@python.org
On 9/26/12 11:26 AM, Andriy Kornatskyy wrote:
> Tarek,
>
> Thank you for the response back. Yes, your idea is pretty clear to me. The point is that higher workload you put in your application business logic, repository, backend, whatever... less you will see in final results comparison. This is obvious and we, as technical people, very well understand this (somebody even laugh).
I am happy somebody got a good laugh, I had a myself a good coffee :)
> Tarek,
>
> Thank you for the response back. Yes, your idea is pretty clear to me. The point is that higher workload you put in your application business logic, repository, backend, whatever... less you will see in final results comparison. This is obvious and we, as technical people, very well understand this (somebody even laugh).
> The reality is that not all web applications do heavy CPU computations and/or experience IO delays (due to response from database running a query over table that has no index, let say), some use caches, some split jobs to be run in background, some parallel them... I have to state that simple things must perform really fast to give more room for one that are not so. That in turn makes your infrastructure more effective. Some prefer to add a box, some see that a likely to be a problem further it goes. The good thing - you have a choice, you are not locked, and as result you are responsible for the effectiveness of the system you build today and definitely next one.
>
> Take care.
>
> Andriy
when you are running it in a given stack, under heavy load ?
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.
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.
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
Same thing for the raw speed of your templating engine - isolation is
required.
One good read:
http://blog.ianbicking.org/2010/03/16/web-server-benchmarking-we-need/
Cheers
Tarek
Dwight Hutto
Sep 26, 2012, 5:48:48 AM9/26/12
to Tarek Ziadé, pytho...@python.org
to Andriy
You can use a framework, however, the function from the framework has
to be used, and the parameters utilized by the frameworks functions.
It would seem that writing your own witin the main page, or using the
original function in place from the framework would run a timeit
better.
I'll look later, but it seems correct in terms of enhancing the
frameworks estimated(OS ops)time to completion.
Andriy Kornatskyy
5:39 AM (5 minutes ago)
to me
David,
This makes sense... and probably can pretend to be most accurate.
Well, in a higher level language, such as Python, you have to remove
layers in order to reduce interpreter completion time.
So just the usage of a framework makes you utilize a function that has
to be imported, accessed and run before the function completes using
the parameters.
It might be faster if you just used the function itself, or optimized it.
You can use a framework, however, the function from the framework has
to be used, and the parameters utilized by the frameworks functions.
It would seem that writing your own witin the main page, or using the
original function in place from the framework would run a timeit
better.
I'll look later, but it seems correct in terms of enhancing the
frameworks estimated(OS ops)time to completion.
Andriy Kornatskyy
5:39 AM (5 minutes ago)
to me
David,
This makes sense... and probably can pretend to be most accurate.
Well, in a higher level language, such as Python, you have to remove
layers in order to reduce interpreter completion time.
So just the usage of a framework makes you utilize a function that has
to be imported, accessed and run before the function completes using
the parameters.
It might be faster if you just used the function itself, or optimized it.
Andriy Kornatskyy
Sep 26, 2012, 6:06:53 AM9/26/12
to dwight...@gmail.com, ta...@ziade.org, pytho...@python.org
David / Tarek,
I believe you and Tarek are pointing the same things. If we want to get that far, we need, first of all, itemize the functions list and find their correspondences in other frameworks... or provide some script of potential calls to framework internal and translate those call to be specific for each framework. In this case we can profile results, capture benchmarks (e.g. with `timeit`) and figure out something more meaningful... yet point framework developers to attention.
Does that sound like a thing you are trying to communicate?
Thanks.
Andriy
----------------------------------------
> Date: Wed, 26 Sep 2012 05:48:48 -0400
> Subject: Re: Fastest web framework
> From: dwight...@gmail.com
> To: ta...@ziade.org
> CC: andriy.k...@live.com; pytho...@python.org
Andriy Kornatskyy
Sep 27, 2012, 5:44:42 AM9/27/12
to pytho...@python.org
CherryPy is in the list now.
http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
Thanks.
Andriy
> Subject: RE: Fastest web framework
> Date: Tue, 25 Sep 2012 13:52:25 +0300
>
>
> The post has been updated with two more frameworks (per community request): tornado and web2py.
>
>
> The post has been updated with two more frameworks (per community request): tornado and web2py.
>
> Comments or suggestions are welcome.
>
> Thanks.
>
> Andriy Kornatskyy
>
>
>
> Thanks.
>
> Andriy Kornatskyy
>
>
> ----------------------------------------
> > From: andriy.k...@live.com
> > To: pytho...@python.org
> > Subject: Fastest web framework
> > Date: Sun, 23 Sep 2012 12:19:16 +0300
> >
> >
> > From: andriy.k...@live.com
> > To: pytho...@python.org
> > Subject: Fastest web framework
> > Date: Sun, 23 Sep 2012 12:19:16 +0300
> >
> >
> > I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
> >
> > http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >
> > Comments or suggestions are welcome.
> >
> > Thanks.
> >
> > Andriy Kornatskyy
> >
> > --
> >
> > http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >
> > Comments or suggestions are welcome.
> >
> > Thanks.
> >
> > Andriy Kornatskyy
> >
> > http://mail.python.org/mailman/listinfo/python-list
>
> --
> http://mail.python.org/mailman/listinfo/python-list
Prasad, Ramit
Sep 27, 2012, 1:53:15 PM9/27/12
to pytho...@python.org
Andriy Kornatskyy wrote:
> Try to see 'Hello World' benchmark as an answer to the question how effective
> is the framework inside...
>
> If computer X boots faster than Y, it means it is more effective in this
> particular area.
>
> If a sportsman runs a distance 1 second faster than other, he got a medal (it
> is not quite adequate to say if I load sportsman with 50 kilo bag he will not
> run that fast... just try split the concerns).
>
> Thanks.
>
> Andriy
>
Not really, it depends on what each computer is doing during
> Try to see 'Hello World' benchmark as an answer to the question how effective
> is the framework inside...
>
> If computer X boots faster than Y, it means it is more effective in this
> particular area.
>
> If a sportsman runs a distance 1 second faster than other, he got a medal (it
> is not quite adequate to say if I load sportsman with 50 kilo bag he will not
> run that fast... just try split the concerns).
>
> Thanks.
>
> Andriy
>
boot.
To switch to the sportsman analogy, if sportsman A has to run
1 mile and along the way pick up 1 lb/kg every .1 mile while
sportsman B has to pick up all the weight at the start.
It is conceivable that sportsman A runs completes the run in
10 minutes while sportsman B runs the time in 9 minutes.
Sportsman A might run the first .1 miles faster (sportsman A
"boots" faster, but that is most likely less important than
the overall long-term/real-world time to complete the task.
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
Andriy Kornatskyy
Sep 29, 2012, 5:18:32 AM9/29/12
to Tarek Ziade, pytho...@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 ?
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.
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.
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
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.
number distinct functions used:
https://bitbucket.org/akorn/wheezy.template/src/tip/demos/bigtable/bigtable.py
Original post not updated yet.
Sounds not so bad. It points to some specific workloads. Any attempt to prioritize
and/or practically implement them?
Thanks.
Andriy
----------------------------------------
> Date: Wed, 26 Sep 2012 11:41:26 +0200
> Subject: Re: Fastest web framework
>
>
> >> Date: Wed, 26 Sep 2012 11:08:19 +0200
> >> From: ta...@ziade.org
> >> To: andriy.k...@live.com
> >> CC: pytho...@python.org
> >> From: ta...@ziade.org
> >> To: andriy.k...@live.com
> >> CC: pytho...@python.org
> >> Subject: Re: Fastest web framework
> >>
> >>
> >>>> Subject: Re: Fastest web framework
> >>>>
> >>>>
> >>>> On 9/23/12 11:19 AM, Andriy Kornatskyy wrote:
> >>>>> I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
> >>>>>
> >>>>> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >>>>>
> >>>>> Comments or suggestions are welcome.
> >>>>>
> >>>>> Thanks.
> >>>>>
> >>>>> Andriy Kornatskyy
> >>>>>
> >>>>>
> >>>>> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >>>>>
> >>>>> Comments or suggestions are welcome.
> >>>>>
> >>>>> Thanks.
> >>>>>
> >>>>> Andriy Kornatskyy
> >>>>>
Andriy Kornatskyy
Oct 2, 2012, 9:17:40 AM10/2/12
to Tarek Ziade, pytho...@python.org
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.k...@live.com
> To: ta...@ziade.org
> Subject: RE: Fastest web framework
> Date: Sat, 29 Sep 2012 12:18:32 +0300
> CC: pytho...@python.org
Andriy Kornatskyy
Oct 9, 2012, 9:44:19 AM10/9/12
to pytho...@python.org
How fast python web framework process routing (URL dispatch)?
Here is a benchmark for various web frameworks (bottle, django, flask, pyramid, tornado and wheezy.web) running the following routing: static, dynamic, SEO and missing... with a trivial 'hello world' application (all routes are pointing to the same handler).
http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
Benchmark is executed in isolated environment using CPython 2.7.
Comments or suggestions are welcome.
Thanks.
Andriy Kornatskyy
> From: andriy.k...@live.com
> To: pytho...@python.org
> Subject: Fastest web framework
> Date: Sun, 23 Sep 2012 12:19:16 +0300
>
>
> To: pytho...@python.org
> Subject: Fastest web framework
> Date: Sun, 23 Sep 2012 12:19:16 +0300
>
>
> I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
> Comments or suggestions are welcome.
>
> Thanks.
>
> Andriy Kornatskyy
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
> Thanks.
>
> Andriy Kornatskyy
>
> --
Andriy Kornatskyy
Oct 15, 2012, 9:39:30 AM10/15/12
to pytho...@python.org
How fast python web frameworks reverse urls?
While routing is a mapping of incoming request to a handler, url reverse function is designed to build urls for those handlers. A web page may have a number of urls from few dozen to hundreds... all related to your web site (e.g. links between related pages, tag cloud, most viewed posts, etc).
Here is a benchmark for various web frameworks (django, flask, pyramid, tornado and wheezy.web):
http://mindref.blogspot.com/2012/10/python-web-reverse-urls-benchmark.html
Benchmark is executed in isolated environment using CPython 2.7. Source is here:
https://bitbucket.org/akorn/helloworld/src/tip/03-urls
Comments or suggestions are welcome.
Thanks.
Andriy Kornatskyy
alex23
Oct 15, 2012, 9:26:16 PM10/15/12
to
On Oct 15, 11:40 pm, Andriy Kornatskyy <andriy.kornats...@live.com>
wrote:
frameworks; ease of use & readily re-usable 3rd party code figures
much higher, IMO. Rather than constantly hammer on about performance,
maybe you could take the time to explain any other advantages your
framework provides.
wrote:
> Comments or suggestions are welcome.
Performance speed is possibly the least interesting aspect of web
frameworks; ease of use & readily re-usable 3rd party code figures
much higher, IMO. Rather than constantly hammer on about performance,
maybe you could take the time to explain any other advantages your
framework provides.
Andriy Kornatskyy
Oct 16, 2012, 6:02:00 AM10/16/12
to pytho...@python.org
Per community request I have updated benchmarks for web2py 2.1.1 release (the newer version performs 26% better; no error while running on pypy):
Here are updated posts, just in case:
http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
Thanks.
Andriy
> Subject: RE: Fastest web framework
> Date: Tue, 9 Oct 2012 16:44:19 +0300
>
>
> How fast python web framework process routing (URL dispatch)?
>
> Here is a benchmark for various web frameworks (bottle, django, flask, pyramid, tornado and wheezy.web) running the following routing: static, dynamic, SEO and missing... with a trivial 'hello world' application (all routes are pointing to the same handler).
>
> http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
>
>
> How fast python web framework process routing (URL dispatch)?
>
> Here is a benchmark for various web frameworks (bottle, django, flask, pyramid, tornado and wheezy.web) running the following routing: static, dynamic, SEO and missing... with a trivial 'hello world' application (all routes are pointing to the same handler).
>
> http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
>
> Benchmark is executed in isolated environment using CPython 2.7.
>
>
> Comments or suggestions are welcome.
>
> Thanks.
>
>
> Andriy Kornatskyy
>
> > From: andriy.k...@live.com
> > To: pytho...@python.org
> > Subject: Fastest web framework
> > Date: Sun, 23 Sep 2012 12:19:16 +0300
> >
> >
> > I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
> >
> > http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >
> > From: andriy.k...@live.com
> > To: pytho...@python.org
> > Subject: Fastest web framework
> > Date: Sun, 23 Sep 2012 12:19:16 +0300
> >
> >
> > I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
> >
> > http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> >
> > Comments or suggestions are welcome.
> >
> >
> > Thanks.
> >
> > Andriy Kornatskyy
> >
> > --
> > http://mail.python.org/mailman/listinfo/python-list
>
> --
> >
> > Andriy Kornatskyy
> >
> > --
> > http://mail.python.org/mailman/listinfo/python-list
>
> http://mail.python.org/mailman/listinfo/python-list
Andriy Kornatskyy
Oct 16, 2012, 7:49:39 AM10/16/12
to wuw...@gmail.com, pytho...@python.org
Alex,
Thank you, see my answers inline to your comments:
> Performance speed is possibly the least interesting aspect of web
> frameworks;
- code quality (we have PEP8)
- architectural decisions taken
- core team experience
- historical path, etc.
> ease of use & readily re-usable 3rd party code figures
> much higher, IMO.
There is a problem with 3rd party code... it should evolve with framework... so good one become a part of it. 3rd party UI things are good, until you start `customize` them, patch, workaround, etc. This is where pain come from. However, there are exceptions. Can you name few?
> Rather than constantly hammer on about performance,
> maybe you could take the time to explain any other advantages your
> framework provides.
Here is how: use content caching with cache dependency. Read more:
http://packages.python.org/wheezy.http/userguide.html#content-cache
Invest 30 minutes to understand it:
http://packages.python.org/wheezy.web/tutorial.html
All web frameworks are good, some better. It is important what you see as an advantage...
Thanks.
Andriy Kornatskyy
----------------------------------------
> Date: Mon, 15 Oct 2012 18:26:16 -0700
> Subject: Re: Fastest web framework
> From: wuw...@gmail.com
> To: pytho...@python.org
> http://mail.python.org/mailman/listinfo/python-list
Demian Brecht
Oct 16, 2012, 10:08:46 AM10/16/12
to Andriy Kornatskyy, pytho...@python.org, wuw...@gmail.com
Let me say right off the bat that I've taken a brief look through the
code and documentation and found that I wouldn't mind trying it out
for personal projects. So, the intention here is not to slag the
framework.
> Performance and effectivity are related metrics. Longer feature list can not explain why it less effective. An answer to effectivity question might be related to:
> - code quality (we have PEP8)
Any static code analysis such as pylint or pyflakes?
> - architectural decisions taken
What (sample of) decisions? How do they differ from other frameworks?
How will they make my life better?
> - core team experience
Not sure this is entirely relevant (imho). Engineers with great
experience on paper may still make poor decisions and output shoddy
work. Conversely, a new grad (or weekend hacker) may have a solid
understanding and output amazing work.
> - historical path, etc.
What does this mean?
> There is a problem with 3rd party code... it should evolve with framework... so good one become a part of it. 3rd party UI things are good, until you start `customize` them, patch, workaround, etc. This is where pain come from. However, there are exceptions. Can you name few?
[Disclaimer: personal opinion] I couldn't disagree more. A good
framework provides the glue for various subsystems to work amazingly
well together. Perhaps this is why I'm drawn to micro-frameworks and
the likes of Pyramid. No assumptions are made about *how* I'm going to
use the framework. Modularity is good. Do one thing and do it *very*
well. Caching? Use beaker. ORM? Use SQLAlchemy.
> Let me state this: "wheezy.web let you design web application to be able run it at the speed of `hello world`, even database driven one".
This bothers me. It's misleading to newbies and it's just wrong. You
simply *cannot* have a database driven application run at the exact
same performance as a "hello world" app.
code and documentation and found that I wouldn't mind trying it out
for personal projects. So, the intention here is not to slag the
framework.
> Performance and effectivity are related metrics. Longer feature list can not explain why it less effective. An answer to effectivity question might be related to:
> - code quality (we have PEP8)
> - architectural decisions taken
What (sample of) decisions? How do they differ from other frameworks?
How will they make my life better?
> - core team experience
Not sure this is entirely relevant (imho). Engineers with great
experience on paper may still make poor decisions and output shoddy
work. Conversely, a new grad (or weekend hacker) may have a solid
understanding and output amazing work.
> - historical path, etc.
What does this mean?
> There is a problem with 3rd party code... it should evolve with framework... so good one become a part of it. 3rd party UI things are good, until you start `customize` them, patch, workaround, etc. This is where pain come from. However, there are exceptions. Can you name few?
framework provides the glue for various subsystems to work amazingly
well together. Perhaps this is why I'm drawn to micro-frameworks and
the likes of Pyramid. No assumptions are made about *how* I'm going to
use the framework. Modularity is good. Do one thing and do it *very*
well. Caching? Use beaker. ORM? Use SQLAlchemy.
> Let me state this: "wheezy.web let you design web application to be able run it at the speed of `hello world`, even database driven one".
simply *cannot* have a database driven application run at the exact
same performance as a "hello world" app.
Andriy Kornatskyy
Oct 16, 2012, 10:47:00 AM10/16/12
to demian...@gmail.com, pytho...@python.org, wuw...@gmail.com
Demian,
Thank you, I appreciate your input. See below.
> > Performance and effectivity are related metrics. Longer
feature list can not explain why it less effective. An answer to
effectivity question might be related to:
> > - code quality (we have PEP8)
>
> Any static code analysis such as pylint or pyflakes?
> > - architectural decisions taken
>
> What (sample of) decisions? How do they differ from other frameworks?
> How will they make my life better?
> > - core team experience
>
> Not sure this is entirely relevant (imho). Engineers with great
> experience on paper may still make poor decisions and output shoddy
> work. Conversely, a new grad (or weekend hacker) may have a solid
> understanding and output amazing work.
> > - historical path, etc.
>
> What does this mean?
>
> There is a problem with 3rd party code... it should evolve with
framework... so good one become a part of it. 3rd party UI things are
good, until you start `customize` them, patch, workaround, etc. This is
where pain come from. However, there are exceptions. Can you name few?
>
> [Disclaimer: personal opinion] I couldn't disagree more. A good
> framework provides the glue for various subsystems to work amazingly
> well together. Perhaps this is why I'm drawn to micro-frameworks and
> the likes of Pyramid. No assumptions are made about *how* I'm going to
> use the framework. Modularity is good. Do one thing and do it *very*
> well. Caching? Use beaker. ORM? Use SQLAlchemy.
>
> Let me state this: "wheezy.web let you design web application to
be able run it at the speed of `hello world`, even database driven one".
>
> This bothers me. It's misleading to newbies and it's just wrong. You
> simply *cannot* have a database driven application run at the exact
> same performance as a "hello world" app.
Here is how: use content caching with cache dependency. Read more:
http://packages.python.org/wheezy.http/userguide.html#content-cache
Andriy Kornatskyy
Demian Brecht
Oct 16, 2012, 12:07:14 PM10/16/12
to Andriy Kornatskyy, pytho...@python.org
On 10/16/2012 7:47 AM, Andriy Kornatskyy wrote:
I think that my first batch of questions were slightly out of context,
mostly due to a lack of caffeine first thing in the morning. My
understanding at the time was that your "an answer to effectivity" was,
in fact, a list of highlights for wheezy.web (which is why I asked the
questions I did). Having said that..
> The initial decisions taken while building a project might be wrong.
Due to continues backward compatibility, you can not change them even
you wish.
You can always deprecate old functionality in favor of new solutions.
I'd be hard pressed to find a reason to find a reason why something
*can't* be deprecated. It may not be easy at times, but it should always
be doable.
> That glue is usability case: recommendation how to use it with one or
the other.
As long as your framework doesn't require you to fight with it in order
to use another solution. One of my early gripes with Django for example
(ages ago) was that it felt like I had to fight the framework in order
to introduce functionality that wasn't natively supported.
> For you, personally, let me point this again. N.P.
>
> Here is how: use content caching with cache dependency. Read more:
> http://packages.python.org/wheezy.http/userguide.html#content-cache
It doesn't matter if you're using cached content or not. It will *not*
be as fast as a hard-coded, simple response (not that a static,
hard-coded response is the way to go obviously). I don't think I have to
get into the details about I/O. My point is simply that the statement
that a database driven site (cached content or not), *can not* be as
fast as a "hello world" app. My comment may be construed as being
nit-picky, but I thought it was worth calling out due to the
matter-of-fact wording that you used.
On a somewhat unrelated note, I caught a minor typo in the content-cache
docs:
"Since there is no heavy processing and just simple operation to get an
item from cache it should be supper fast"
I don't know about you, but my supper generally isn't fast ;)
I think that my first batch of questions were slightly out of context,
mostly due to a lack of caffeine first thing in the morning. My
understanding at the time was that your "an answer to effectivity" was,
in fact, a list of highlights for wheezy.web (which is why I asked the
questions I did). Having said that..
> The initial decisions taken while building a project might be wrong.
Due to continues backward compatibility, you can not change them even
you wish.
I'd be hard pressed to find a reason to find a reason why something
*can't* be deprecated. It may not be easy at times, but it should always
be doable.
> That glue is usability case: recommendation how to use it with one or
the other.
to use another solution. One of my early gripes with Django for example
(ages ago) was that it felt like I had to fight the framework in order
to introduce functionality that wasn't natively supported.
> For you, personally, let me point this again. N.P.
>
> Here is how: use content caching with cache dependency. Read more:
> http://packages.python.org/wheezy.http/userguide.html#content-cache
be as fast as a hard-coded, simple response (not that a static,
hard-coded response is the way to go obviously). I don't think I have to
get into the details about I/O. My point is simply that the statement
that a database driven site (cached content or not), *can not* be as
fast as a "hello world" app. My comment may be construed as being
nit-picky, but I thought it was worth calling out due to the
matter-of-fact wording that you used.
On a somewhat unrelated note, I caught a minor typo in the content-cache
docs:
"Since there is no heavy processing and just simple operation to get an
item from cache it should be supper fast"
I don't know about you, but my supper generally isn't fast ;)
Andriy Kornatskyy
Oct 16, 2012, 12:35:39 PM10/16/12
to demian...@gmail.com, pytho...@python.org
Demian,
Thank you, see below.
> I think that my first batch of questions were slightly out of context,
> mostly due to a lack of caffeine first thing in the morning. My
> understanding at the time was that your "an answer to effectivity" was,
> in fact, a list of highlights for wheezy.web (which is why I asked the
> questions I did). Having said that..
>
> > The initial decisions taken while building a project might be wrong.
> Due to continues backward compatibility, you can not change them even
> you wish.
>
> You can always deprecate old functionality in favor of new solutions.
> I'd be hard pressed to find a reason to find a reason why something
> *can't* be deprecated. It may not be easy at times, but it should always
> be doable.
> > That glue is usability case: recommendation how to use it with one or
> the other.
>
> As long as your framework doesn't require you to fight with it in order
> to use another solution. One of my early gripes with Django for example
> (ages ago) was that it felt like I had to fight the framework in order
> to introduce functionality that wasn't natively supported.
>
> > For you, personally, let me point this again. N.P.
> >
> > Here is how: use content caching with cache dependency. Read more:
> > http://packages.python.org/wheezy.http/userguide.html#content-cache
>
> It doesn't matter if you're using cached content or not. It will *not*
> be as fast as a hard-coded, simple response (not that a static,
> hard-coded response is the way to go obviously). I don't think I have to
> get into the details about I/O. My point is simply that the statement
> that a database driven site (cached content or not), *can not* be as
> fast as a "hello world" app. My comment may be construed as being
> nit-picky, but I thought it was worth calling out due to the
> matter-of-fact wording that you used.
http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
> On a somewhat unrelated note, I caught a minor typo in the content-cache
> docs:
>
> "Since there is no heavy processing and just simple operation to get an
> item from cache it should be supper fast"
>
> I don't know about you, but my supper generally isn't fast ;)
Somewhat later in a week there will be another benchmark for... caching.
Take care.
Andriy
Andriy Kornatskyy
Oct 25, 2012, 9:47:27 AM10/25/12
to pytho...@python.org
Web content caching is the most effective type of cache. This way your python handler is not executed to determine a valid response to user, instead one returned from cache. Since the operation is that simple, it should be the maximum possible speed your `real world` application capable to provide.
The web content caching benchmark is provided for two types of caching: memory and distributed. There is payed attention how gzip transform impact throughput of cached content. Read more here:
http://mindref.blogspot.com/2012/10/python-web-caching-benchmark.html
Your ability to utilize managed (semi-real time) caching is essential to be able run your `real world` at the speed of `hello world`. Read more here:
http://packages.python.org/wheezy.http/userguide.html#content-cache
http://packages.python.org/wheezy.web/tutorial.html
Compare throughput with numbers from the other post:
http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
Comments or suggestions are welcome.
Andriy Kornatskyy
> Subject: Fastest web framework
> Date: Sun, 23 Sep 2012 12:19:16 +0300
>
>
> I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
> Date: Sun, 23 Sep 2012 12:19:16 +0300
>
>
> I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
> Comments or suggestions are welcome.
>
>
Andriy Kornatskyy
Oct 26, 2012, 6:53:10 AM10/26/12
to wuw...@gmail.com, pytho...@python.org
Alex,
You can read wheezy.web introduction here:
http://mindref.blogspot.com/2012/10/wheezy-web-introduction.html
Thanks.
Andriy Kornatskyy
----------------------------------------
> Date: Mon, 15 Oct 2012 18:26:16 -0700
> Subject: Re: Fastest web framework
> From: wuw...@gmail.com
> To: pytho...@python.org
>
> http://mail.python.org/mailman/listinfo/python-list
Andriy Kornatskyy
Nov 1, 2012, 7:36:26 AM11/1/12
to pytho...@python.org
Per community request turbogears and pysi were added. The following posts have been updated:
http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
http://mindref.blogspot.com/2012/10/python-web-pep8-consistency.html
Comments or suggestions are welcome.
Andriy
----------------------------------------
> From: andriy.k...@live.com
> To: pytho...@python.org
> Subject: Fastest web framework
> Date: Sun, 23 Sep 2012 12:19:16 +0300
>
>
> I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting:
>
> http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
>
> Comments or suggestions are welcome.
>
>
0 new messages