Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #31301 > unrolled thread

RE: Fastest web framework

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: Fastest web framework Andriy Kornatskyy <andriy.kornatskyy@live.com> - 2012-10-15 16:39 +0300
    Re: Fastest web framework alex23 <wuwei23@gmail.com> - 2012-10-15 18:26 -0700
      RE: Fastest web framework Andriy Kornatskyy <andriy.kornatskyy@live.com> - 2012-10-16 14:49 +0300
      Re: Fastest web framework Demian Brecht <demianbrecht@gmail.com> - 2012-10-16 07:08 -0700
      RE: Fastest web framework Andriy Kornatskyy <andriy.kornatskyy@live.com> - 2012-10-16 17:47 +0300
      Re: Fastest web framework Demian Brecht <demianbrecht@gmail.com> - 2012-10-16 09:07 -0700
      RE: Fastest web framework Andriy Kornatskyy <andriy.kornatskyy@live.com> - 2012-10-16 19:35 +0300
      RE: Fastest web framework Andriy Kornatskyy <andriy.kornatskyy@live.com> - 2012-10-26 13:53 +0300

#31301 — RE: Fastest web framework

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


----------------------------------------
> From: andriy.kornatskyy@live.com
> To: python-list@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
 		 	   		  

[toc] | [next] | [standalone]

#31352

On Oct 15, 11:40 pm, Andriy Kornatskyy <andriy.kornats...@live.com>
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.

[toc] | [prev] | [next] | [standalone]

#31391

Alex,

Thank you, see my answers inline to your comments:

> Performance speed is possibly the least interesting aspect of web
> frameworks;

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
- core team experience
- historical path, etc.

> ease of use & readily re-usable 3rd party code figures
> much higher, IMO.

I think these are very valid requirements for the modern web framework. I believe all web frameworks are easy to use (... some too seriously take this?), of cause readability/flexibility counts.

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.

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".

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: wuwei23@gmail.com
> To: python-list@python.org
>
> On Oct 15, 11:40 pm, Andriy Kornatskyy <andriy.kornats...@live.com>
> 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.
> --
> http://mail.python.org/mailman/listinfo/python-list
 		 	   		  

[toc] | [prev] | [next] | [standalone]

#31403

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.

[toc] | [prev] | [next] | [standalone]

#31408

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?

Yep, good start with any of those.

> > - architectural decisions taken
>
> What (sample of) decisions? How do they differ from other frameworks?
> How will they make my life better?

The initial decisions taken while building a project might be wrong. Due to continues backward compatibility, you can not change them even you wish. Some projects die and same people start a new one, rethinking mistakes made.

> > - 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.

The question is about the practical things you do daily. You might laugh of your first project, you continue to move forward and got respect as it is now. Imagine you continue to fix your first program up to now, you will probably write is somewhat differently. Same applies to frameworks, pursue effectiveness for more: users served, application hosted, etc. Some, just can not.

> > - historical path, etc.
>
> What does this mean?

The frameworks are not written in one day, they have historical path with many hands on it. This change it, not always right way.

>
 > 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.

That glue is usability case: recommendation how to use it with one or the other.

>
 > 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.

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
 
Thanks.

Andriy Kornatskyy
 		 	   		  

[toc] | [prev] | [next] | [standalone]

#31415

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 ;)

[toc] | [prev] | [next] | [standalone]

#31417

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.

And that is the problem. Some can not deprecate and die (see pylons, now pyramid). Some can not die nor deprecate (see django).

> > 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.

It does. There is certain level after which performance of `hello world` will not differ from real world application. The hardware I used got that limit at 22-24K per second. That is why I made isolated benchmarks. See difference between wsgi sample and others.

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 ;)

You will see. Thanks. supper => super ;-)

Somewhat later in a week there will be another benchmark for... caching.

Take care.

Andriy
 		 	   		  

[toc] | [prev] | [next] | [standalone]

#32209

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: wuwei23@gmail.com
> To: python-list@python.org
>
> On Oct 15, 11:40 pm, Andriy Kornatskyy <andriy.kornats...@live.com>
> 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.
> --
> http://mail.python.org/mailman/listinfo/python-list
 		 	   		  

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web