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 -- http://mail.python.org/mailman/listinfo/python-list
