Fastest web framework
andriy.kornatskyy at live.com
Tue Oct 16 18:35:39 CEST 2012
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.
> On a somewhat unrelated note, I caught a minor typo in the content-cache
> "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.
More information about the Python-list