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.
> > 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
> 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:
> > 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:
> > 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.
> Great, thanks for the update ! -- that's cool to bench the template
> 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.
> >> 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:
> >> 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.
> 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 :)
> 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
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 ?
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.
>> 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
>> 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:
>>> 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:
>>> 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.
>> Great, thanks for the update ! -- that's cool to bench the template
>> 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.
>>>> 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:
>>>> 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.
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.
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?
> 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.
> > 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:
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
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.
> 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.
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:
> > 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 :)
> > 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
> 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 ?
> 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.
> >>> 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
> >> 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:
> >>> 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:
> >>> 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.
> >> Great, thanks for the update ! -- that's cool to bench the template
> >> 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.
> >>>> 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:
> >>>> 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.
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.
> > 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.
> 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:
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).
> From: andriy.kornats...@live.com
> To: python-l...@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:
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):
> From: andriy.kornats...@live.com
> To: python-l...@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:
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.
> From: andriy.kornats...@live.com
> To: python-l...@python.org
> 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).
> > 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:
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".
> Date: Mon, 15 Oct 2012 18:26:16 -0700
> Subject: Re: Fastest web framework
> From: wuwe...@gmail.com
> To: python-l...@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
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.
> > 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.
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.
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.
> 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.
> 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.
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:
> From: andriy.kornats...@live.com
> To: python-l...@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:
> Date: Mon, 15 Oct 2012 18:26:16 -0700
> Subject: Re: Fastest web framework
> From: wuwe...@gmail.com
> To: python-l...@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
> From: andriy.kornats...@live.com
> To: python-l...@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:
