BTW... I had a Turion64. It is not a very fast machine.
On Jun 5, 12:03 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> Can you tell us more about the setup, os, hardward etc. is mysql on
> the same machine?
> How much is the the SQLDB() vs the define_tables? Do you have many
> tables? how long?
>
> One trick is to add is statements in the model so that only those
> tables needed are defined, depending on request.controller and
> request.action.
>
> On Jun 5, 11:29 am, Alexey Nezhdanov <snak...@gmail.com> wrote:
>
> > On Friday 05 June 2009 17:07:55 mdipierro wrote:> In a production
> > environment you would be using mysql or postgresql. In
> > > this case you should be using
>
> > > SQLDB(...,pool_size=10)
> > > dn.define_table(....,migrate=False)
>
> > > the connection pooling and migrations off make a big difference.
> > > Perhaps you can run some tests and quantify this.
>
> > migrate=False makes cuts the model init time in half - now I'm getting about
> > 0.15-0.17s each time. Testing MySQL, stand by...
>
> > Hmmm.
> > 0.21...0.25s with mysql and migrations off... and pool_size=10.
>
> > > When using sqlite you cannot use pooling and that means web2py has to
> > > open the db every time.
>
> > > Massimo
>
> > > On Jun 5, 2:58 am, Alexey Nezhdanov <snak...@gmail.com> wrote:
> > > > Hello again.
> > > > Recently I measured the perfomance of web2py regarding to 'milliseconds
> > > > per request'. Got some unexpected results. The most slow part of the
> > > > application is the model. It takes 40-60% of total time. Measurement was
> > > > done simply by putting
> > > > import time;print time.time(),'model start'
> > > > at the beginning of db.py and similar line at the end of it. Here is
> > > > what
> > > > it produces on my laptop (Turion64, 1.6GHz, 1.5G RAM):
>
> > > > 1244187446.32 model start
> > > > 1244187446.62 model stop
> > > > 0.3 second just to set up the model! I can live with 0.05 for it, may be
> > > > even 0.1, but 0.3 for _each_ GET or POST request is a bit too much,
> > > > don't
> > > > you think?
> > > > That is for not too complex model - 17 tables, averaging 8.6 SQLFields
> > > > per one. On another web2py project it takes 0.38...0.42 second each time
> > > > :(
>
> > > > I tried compiling my app and measuring again:
> > > > 1244187625.31 model start
> > > > 1244187625.69 model stop
> > > > Not any better. In fact, it's even worse, but since results vary from
> > > > run
> > > > to run I suspect that it is just the same perfomance.
>
> > > > Massimo, as I know you've been working on new model for some time
> > > > already. Is there any hope of having a faster model? I suspect more lazy
> > > > evaluation should do the magic, but I didn't do any research yet.
>
> > > > Frankly speaking when I first discovered the fact that web2py always
> > > > _executes_ model, controller, view, I thought that it may be a
> > > > perfomance
> > > > hog. Until I actually did that check I thought that it will execute
> > > > db.py
> > > > each time it changes on-disk and then just keep built structures
> > > > somewhere around, probably pickled. May be it is still possible to use
> > > > that approach to some extent?
>
> > > > Or may be I am just completely missing the point. Please comment.
>
> > > > --
> > > > Sincerely yours
> > > > Alexey Nezhdanov
>
> > --
> > Sincerely yours
> > Alexey Nezhdanov
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
