ON Saturday 06 June 2009 00:25:47 mdipierro wrote:
> One other trick you can try is replace
>
> db.define_table('table',SQLField('field'),...)
> db.table.field.requires=....
>
> with
>
> db.define_table('table',SQLfield('field',requires=...),...)
>
> and so for all the other attributes.
That will make minor difference. I do not have too many 'requires' and mod of
what I have are set up through function call.
> Did you bytecode compile the app?
> Does it make a difference?
I just run some automated tests. Here is average time over 100 runs each:
sqlite+nomigrate+py 0.123
sqlite+nomigrate+pyc 0.122
mysql+nomigrate+py 0.123
mysql+nomigrate+pyc 0.123
I think I'll try this approach:
1) define each table as a function which yelds a table.
2) modify sql.py so that db object will test the type of table.
if it has __exec__ method - execute it and replace it with return result.
This way my tables will be lazily defined when controller actually needs them.
> Massimo
>
> On Jun 5, 3:05 pm, Alexey Nezhdanov <[email protected]> wrote:
> > On Friday 05 June 2009 21:03:20 mdipierro wrote:> Can you tell us more
> > about the setup, os, hardward etc. is mysql on
> >
> > > the same machine?
> >
> > Kubuntu 8.04. Turion64 1.6GHz, 1.6G RAM. MySQL is on the same box. SiS
> > motherboard w/ nForce chipset. Laptop 3 years old (and it was about 1
> > year old model when was bought).
> >
> > > How much is the the SQLDB() vs the define_tables? Do you have many
> > > tables? how long?
> >
> > 16 tables, 152 SQLFields. single SQLDB (currently MySQL, but I'll switch
> > it back to SQLite)
> >
> > > 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.
> >
> > yes, I thought of that. But that makes it inflexible. That's why I
> > suggested lazy tables init.
> >
> > And regarding 'turion is not very fast'. I don't really have any load on
> > this box. So 0.5 seconds per GET is VERY slow. 8-years old Celeron 800
> > should be behaving something like 0.05 seconds per request (of course
> > with ad-hoc programming, no DAL).
> >
> > This is not the empty complaint. We can't really afford saying 'throw in
> > more CPU'. If web2py targets GAE - then it absolutely must be
> > CPU-friendly. GAE can help with adding more nodes but it charges for
> > processor time anyways. And actually the same goes about dedicated
> > hosting too. If someone targets only a few visitors per day - it's ok.
> > But not if we want tens and hundreds pageloads per second.
> >
> > > On Jun 5, 11:29 am, Alexey Nezhdanov <[email protected]> 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 <[email protected]> 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
> >
> > --
> > 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 [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
-~----------~----~----~----~------~----~------~--~---
