The permance test of 6 leading web-frameworks.

[Alrond]

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/

[Richard Clark]

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.

[Christoph Zwerschke]

Richard Clark wrote:
> 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.

Exactly. You cannot make any really meaningful statements if you only
look at static "Hello Word" examples. Neither about execution time nor
about development time (as done in Joel Spolsky's nevertheless
interesting screencast http://oodt.jpl.nasa.gov/better-web-app.mov).

-- Chris

[Adam Jones]

Although it is now out of date (and does TG a huge disservice at this
point in time), that comparison is still worlds more useful than this
one in that it focuses on the right subject. Performance is (largely)
a solvable problem for web apps. Making web development easier is
still something that we are all exploring. Since that, and not raw
speed, is the focus of every platform on the list above, I would
advise anyone still looking for their solution to weigh out how their
chosen framework will help them get their app written, chances are
that you will have more tools than you need to handle performance when/
if it becomes an issue.

-Adam

[iain duncan]

Nor does it make any sense to compare hit times using the default
templates when

a) changing template engines is easy and will vastly change that stat
b) the purpose of the various template engines is quite different as
regards the high level programming vs speed equation, with kid and
genshi being xml parsed and django and cheetah being text templates

Iain

[iain duncan]

Exactly. Or as I like to say:
"You know what's REALLY fast? CGI in C!" ;)

;) - said with much love for C as a hobby audio and microcontroller
hacker
Iain

[Jorge Vargas]

On 1/30/07, Christoph Zwerschke <ci...@online.de> wrote:

Richard Clark wrote:
> 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.

on this I agree

Exactly. You cannot make any really meaningful statements if you only
look at static "Hello Word" examples. Neither about execution time nor
about development time (as done in Joel Spolsky's nevertheless
interesting screencast http://oodt.jpl.nasa.gov/better-web-app.mov).

huh?  what are you talking about that was done by Sean Kelly from the plone team, which by the way says his name a couple of times in the screencast http://plone.org/about/movies

-- Chris

[Christoph Zwerschke]

Jorge Vargas wrote:

> Christoph Zwerschke wrote:
> Exactly. You cannot make any really meaningful statements if you only
>> look at static "Hello Word" examples. Neither about execution time nor
>> about development time (as done in Joel Spolsky's nevertheless
>> interesting screencast http://oodt.jpl.nasa.gov/better-web-app.mov).
>
> huh? what are you talking about that was done by Sean Kelly from the plone
> team, which by the way says his name a couple of times in the screencast
> http://plone.org/about/movies

Yerry sorry, yes this was made by Sean Kelly. I think I got confused
because I copied the link here from Joel's discussion group:
http://discuss.joelonsoftware.com/default.asp?joel.3.314850.18

-- Chris

[Alrond]

I have conducted the small additional test.
So by requests I tested TurboGears with various template engines: Kid,
Cheetah, Genshi and Jinja
http://www.alrond.com/en/2007/feb/04/in-addition-to-the-test-of-mvc-frameworks/

[lateef jackson]

I want to take this opportunity to ask for some help. Right now I am working a draft for Optimization for TG. If anyone can fire away and email me on or off the list with topics suggestions or what every I am going to try and cover things based on most common performance errors (bad queries, excessive looping ect) and low hanging fruit (built in SQLObject caching, Cheetah cache ect) first. After that we can cover more advanced topics.

Thanks,
Lateef

[lasizoillo]

Setting the debug variable in a connection uri (SO) you can debug your db querys
example:
mysql://host/database?debug=1

This is usefull for execute a explain plan* of query execution,
redefine index in your db or refactor into better querys.

* PostgreSQL: http://www.postgresql.org/docs/7.4/interactive/sql-explain.html
* MySQL: http://dev.mysql.com/doc/refman/5.0/en/explain.html

Thanks for the doc page ;-)

2007/2/7, lateef jackson <lateef....@gmail.com>:

[gasolin]

> I have conducted the small additional test.
> So by requests I tested TurboGears with various template engines: Kid,

> Cheetah, Genshi and Jinja http://www.alrond.com/en/2007/feb/04/in-addition-to-the-test-of-mvc-f...

Hello,

Thanks for your sharing, I'd like to sugget a cleaner example code
which is equivalent to django's :-)

# more turbogears-ic

from turbogears import controllers, expose

class Root(controllers.RootController):
@expose(template="tg.templates.world")
def index(self):
return dict(hello_world="Hello World!") # eqal to
{'hello_world': "Hello World!"}

the kid template is:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://
www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:py="http://purl.org/
kid/ns#">
<body>
<div py:content="hello_world"></div>
</body>
</html>

logging, <?pyhton ?> and "py:extend" statement are not essential for
turbogears,
and they may take extra time in this performance evaluation.

--
Fred