Web frameworks speed comparisons (not again!)
Christopher Arndt
Some of you may have stumbled upon
through the Planet TurboGears or otherwise and so did I. I thought it
would be interesting to port the TurboGears 2 example to TG 1.1 and so I
did:
http://chrisarndt.de/projects/wf-shootout/
I only ran the benchmark for TG 1.1, 1.5 SVN (same code as for 1.1) and
TG 2.0.3 on my system, but the results were interesting and I learned a
few things.
a) TG 1.x is about 25% faster than TG2 for this simple application.
b) TG 1.5 is even faster than 1.1 but a bit inconsistent (e.g. Genshi
very slow).
c) Since TG 1.1 changed the template engine option loading mechanism, it
is now much easier to integrate alternative template engine plugins. For
example, I included the code for a Jinja2 buffet plugin, since the
Jinja2 distribution does not seem to contain such a plugin any more. It
requires that you set some options in the TG config, which, thanks to
the afore mentioned change, is not a problem. I'll write some docs on
using Jinja2 with TG1 on the wiki soon.
d) Jinja2 is consistently marginally faster than Mako for this application.
e) Porting a simple TG2 application like this to TG 1 (not the other way
round!) was very easy! :) No authentication features used here, though.
Feel free to download the code and experiment for yourself. A script to
run the apache benchmark tool on the application is included in the package.
Chris
Graham Dumpleton
On Oct 9, 10:38 am, Christopher Arndt <chris.ar...@web.de> wrote:
> Is it that time of the year again? ;)
>
> Some of you may have stumbled upon
>
> through the Planet TurboGears or otherwise and so did I. I thought it
> would be interesting to port the TurboGears 2 example to TG 1.1 and so I
> did:
>
> http://chrisarndt.de/projects/wf-shootout/
>
> I only ran the benchmark for TG 1.1, 1.5 SVN (same code as for 1.1) and
> TG 2.0.3 on my system, but the results were interesting and I learned a
> few things.
>
> a) TG 1.x is about 25% faster than TG2 for this simple application.
> b) TG 1.5 is even faster than 1.1 but a bit inconsistent (e.g. Genshi
> very slow).
> c) Since TG 1.1 changed the template engine option loading mechanism, it
> is now much easier to integrate alternative template engine plugins. For
> example, I included the code for a Jinja2 buffet plugin, since the
> Jinja2 distribution does not seem to contain such a plugin any more. It
> requires that you set some options in the TG config, which, thanks to
> the afore mentioned change, is not a problem. I'll write some docs on
> using Jinja2 with TG1 on the wiki soon.
> d) Jinja2 is consistently marginally faster than Mako for this application.
> e) Porting a simple TG2 application like this to TG 1 (not the other way
> round!) was very easy! :) No authentication features used here, though.
>
> Feel free to download the code and experiment for yourself. A script to
> run the apache benchmark tool on the application is included in the package.
more routes you add where matched URL is further and further down that
list of routes?
Note that I do not know how TG handles URL routing, so it may not be a
totally relevant question.
Graham
Christopher Arndt
> Care to comment on my query about how performance may be affected the
> more routes you add where matched URL is further and further down that
> list of routes?
>
> Note that I do not know how TG handles URL routing, so it may not be a
> totally relevant question.
I'm totally not an expert on that question, but for the dimensions you
are quoting, i.e. < 100 rules, I wouldn't expect this to be a measurable
factor.
But this is just guessing and it should be easy to build two
applications to actually measure it...
Chris
Seth
Thanks for throwing TG 1.1 into the list. I'm pretty sure CherryPy is
expected to be faster than the Paste server, so I ran your 1.1 test
app on my mod_wsgi setup and came up with the following: http://bit.ly/1czNm3
For some reason I could not get Mako working. There's a paste link
with the output there in the above link. I'm not at all familiar with
TG 1.x setup so I'm probably just doing something stupid.
Cheers,
Seth
Christopher Arndt
> Thanks for throwing TG 1.1 into the list. I'm pretty sure CherryPy is
> expected to be faster than the Paste server, so I ran your 1.1 test
> app on my mod_wsgi setup and came up with the following: http://bit.ly/1czNm3
So how did you do this exactly? Did you wrap the cherrypy app in a wsgi
app and configured this for mod_wsgi?
> For some reason I could not get Mako working. There's a paste link
> with the output there in the above link. I'm not at all familiar with
> TG 1.x setup so I'm probably just doing something stupid.
Hmm, can't tell from your traceback, what went wrong. You seem to have
all the right package versions. If I look at the code in your zip, and
can see no obvious changes that could have broken something. Have you
checked the permissions on the 'hello.mak' file?
I had similar problems with the Jinja2 plugin first, which I solved the
good old fashioned way by inserting a print statements in the failing
function and the ones calling it, to see what went wrong. Turned out
that Jinja2 was expecting the path to the templates in the configuration
and only the basename of the template in the expose decorator. But it's
not like that for mako, because on my system it works like genshi.
What I find suspicious in the exception you pasted:
TopLevelLookupException: Cant locate template for uri
'/helloworld/templates/hello.mak'
is, that it gives an absolute path for the template.
Btw, I cheated a little bit in the raw_sql method, where I transformed
output = ''
hello = DBSession.query(model.Hello).all()
for row in hello:
output += str(row.id) + ' - ' + row.data + '\n'
return output
from the TG2 app into the more pythonic
output = []
hello = Hello.query.all()
for row in hello:
output.append('%s - %s' % (row.id, row.data))
return '\n'.join(output)
which should be also slightly faster for big datasets.
(Also, the 'hello = Hello.query.all()' line uses the session-aware SA
mapper emulation, which is available since 1.1rc1.)
Chris
Seth
I used Graham's tutorial at:
http://code.google.com/p/modwsgi/wiki/IntegrationWithTurboGears
My mod_wsgi setup in embedded mode does have some permissions issues,
but I've checked and re-checked all the permissions, so I don't know
what could be happening there. Have you tested Mako on a mod_wsgi
setup with TG 1.1? Maybe it's something strange with loading the wsgi
app the way Graham has it outlined there?
Thanks for the tip on the raw_sql output.
Seth
Christopher Arndt
Seth schrieb:
> I used Graham's tutorial at:
>
> http://code.google.com/p/modwsgi/wiki/IntegrationWithTurboGears
>
> My mod_wsgi setup in embedded mode does have some permissions issues,
> but I've checked and re-checked all the permissions, so I don't know
> what could be happening there. Have you tested Mako on a mod_wsgi
> setup with TG 1.1?
No, I haven't tested it yet. I normally use mod_proxy or nginx for my TG
1.1 setups. But I will try to test it soon.
> Maybe it's something strange with loading the wsgi
> app the way Graham has it outlined there?
Looking at the recipe it occurs to me that it might have to do with the
SCRIPT_NAME handling. Earlier TG versions did not support it, so the
turbogears.wsgi script removes it from the environment, but TG 1.1
should fully respect it, so it has to be passed.
Chris
Graham Dumpleton
integration with mod_wsgi into their own documentation and then keep
it up to date with any changes in your package. I would then just
refer to your documentation.
I have given up trying to track all the different packages and sub
variants so any documentation on mod_wsgi site will likely just get
more and more out of date and thus wrong as a result. I have managed
to get a few other packages to do this and so just have references for
them instead now.
Graham
Christopher Arndt
> Any chance the TG team would adopt my documentation on TG 1.1
> integration with mod_wsgi into their own documentation and then keep
> it up to date with any changes in your package. I would then just
> refer to your documentation.
We can put the docs pertaining to TG1 into our wiki, sure. If there is
anything relating to TG2 it should go into the Sphinx docs. I believe
Michael Pedersen is the right contact for this.
I suggest, you just create a page in the rough docs section and I will
bring it into the right form. You'll need a wiki account for this, but
if this is not too much hassle for you, you can send my the doc and I'll
put it on the wiki. ReST format would be much preferred :)
I suggest using this as the place to put the page:
http://docs.turbogears.org/1.1/RoughDocs/DeployModWSGI
You should also open a ticket in our track, so we don't forget this:
http://docs.turbogears.org/DocHelp#document-submission-procedure
As I said, I do not use this setup myself very much, so I wouldn't be
the right person to maintain such a document. But I am sure there are
other who do and together we can try to keep the doc up to date.
> I have given up trying to track all the different packages and sub
> variants so any documentation on mod_wsgi site will likely just get
> more and more out of date and thus wrong as a result. I have managed
> to get a few other packages to do this and so just have references for
> them instead now.
Yes, I think that's the only sensible approach. But is there an easy way
for us to track changes in mod_wsgi that would affect our suggested setup?
Chris
Lukasz Szybalski
Not sure if related, but here are the copy paste instructions that I have used.
http://lucasmanual.com/mywiki/TurboGears#apacheandmodwsgi
Thanks,
Lucas