«

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.ht...#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/...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