On Jan 30, 6:51 am, "Alrond" <[EMAIL PROTECTED]> wrote: > The permance test of 6 leading web-frameworks, with TurboGears > Among six leading web-frameworks the detail analysis was conducted for > decision of the best of these in performance and > stability.http://www.alrond.com/en/2007/jan/25/performance-test-of-6-leading- > frameworks/
You have compared a bunch of high level web development frameworks, whose express purpose is to make development of complex web applications simple, by comparing their most basic performance metrics as if they were HTTP servers. This is the kind of information that would be useful to the people actually developing the frameworks, they might have ended up with some kind of scary latency hidden somewhere, but to anyone else the information is misleading in the extreme. The problem is that at this level of framework, the speed of the final site is a combination of 3 things: The speed of each involved component of the framework (Turbogears has half a dozen, of which you barely tested 2, cherrypy and kid), the speed and nature of the supporting platform (windows? linux? fast disks? lots of cache?), and the supporting optimisations (indexes on tables, memcached, load balancing and pre-caching etc) Hence someone unfamiliar with any of the frameworks, determined to learn one, may be misled by your metrics into believing they should choose one or another on the basis of "speed" when in fact the numbers you have measured are a tiny fraction of that required to make any real statement on the "speed" of a framework, even if you take the reasonable course of ignoring local optimisation. Added to that is the odd choice of forcing FCGI on everyone. You'd have been better to simply deal with the frameworks however they like to work natively, that's where they perform best. I always deploy Turbogears with cherrypy proxied via apache for example. I think you would do better to point out to readers on your blog that they should not be making framework choices based on this kind of speed metric as a primary decision maker. If everything else is a tie (right language, right platform, experience to hand, fit with current environment, fit with developer minset etc) then sure, but looking at the charts and going straight for django on the basis that it was "fast", or dismissing Symfony because it's "slow" is as good as rolling a dice from a project perspective. Nobody in a performance-critical environment will ever deliver static content through the templating system or the application server, so these numbers will never come to light in practice. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
