On Aug24, 6:07pm, what_ho <[email protected]> wrote:
> I did some quick and dirty performance tests to measure the time taken
> by db.define_table calls.
>
> Test was as follows:
> - Run web2py locally, with built-in web server
> - Create new application 'perftest' in web2py admin interface
> - Add 5 dummy table definitions to db.py, uncomment mail and auth
> settings (see copy of my db.py at end of this message)
> - Run the HP tool httperf to access perftest home page 1000 times
> using the following command:
> httperf --hog --server=localhost --port 8000 --uri /perftest/default/
> index --num-conns=1000
> - Time tests with db.py as defined below, with table definitions
> removed, and with db.py file removed completely
>
> To remove the table definitions I commented out the line
> 'auth.define_tables()' and all lines starting 'db.define_table' in
> db.py
>
> For reference I am running Ubuntu Linux (karmic alpha), Intel Dual
> Core 2.0Ghz, 4GB RAM. httperf version used is 0.9.0 (available from
> synaptic package manager). web2py version 1.66.2, python 2.5
>
> Results - time to receive 1000 pages from web2py built-in webserver:
>
> Not compiled:
> Full db.py - 22.4s
> No table defs in db.py - 11.5s
> No db.py at all 9.6s
>
> Compiled:
> Full db.py - 16s
> No table defs - 5.7s
> No db.py at all 4.1s
>
> This does appear to show there would be a performance benefit to
> sharing the db object definitions between page requests.
>
> Yarko - I like your suggestion of putting table definitions in gluon
> just as a quick hack to compare performance - I will try this next.
>
Thanks for the interesting test, Pearson (What_Ho).
Besides of trying Yarko's "putting table definitions in gluon just as
a quick hack to compare performance", would you mind try a more
general way?
A. Put table definitions into applications/yourapp/modules/
yourtable.py, and then just import them from your db.py? I assume
this is enough to bypass the source code parsing overhead in each
request, although the db objects are still rebuild in every request.
B. If you do plan A, you might probably like to do a plan B, just
simply compile your app with full db.py, then benchmark again. Maybe A
and B provide similar result.
C. I am not sure yet, but if plan A helps a bit, we can again use the
cache trick to reuse the same db object for every request. Something
like this:
from applications.yourapp.modules.yourtable import _init_db
db=cache.ram('my_db', _init_db(), 99999999)
Can it give another boost?
Sincerely,
Iceberg
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" 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/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
