[web2py] Re: what's up in DAL?

2011-06-14 Thread Massimo Di Pierro
How many records does it return?

There is a difference. If you execute the query using DAL, web2py
loops over the output and converts the raw output into a database
independent formatting (for example if the database returns a date as
a string, web2py converts that into a datatime.date object) and store
them into a Storage object.


There is no overhead in generating the query from DAL but there is
overhead in normalizing the output.

This is necessary because every database engine will return records in
a different format but web2py needs to make the response database
independent.

If you run with profiler you will find that most of the time is spend
in the function parse.


On Jun 14, 4:34 am, Manuele Pesenti manuele.pese...@gmail.com wrote:
 Hi *,
 I have a quite complex database with a lot of records distributed in
 some tables, I noticed that some query seams too heavy so I tryied to
 understand where is the problem. Looking with the top bash command the
 CPU occupation I saw that after a few seconds (~10 or 15) of mysqld
 occupation starts a long python session that occupy the biggest part of
 the resources (CPU 100%)... so I realized this few code to test what
 happens.

 It's possible to see that the same query executed via executesql is
 considerably faster than via DAL... here you can see the results of two
 different query in which I duplicate the time interval...

 t0 = datetime.datetime.today()
 sql_query = db(join  where)._select(*what, left=left_join, orderby=order)
 print 'query constraction: ', datetime.datetime.today() - t0

 - query constraction:  0:00:00.002458 (second try: query constraction:
   0:00:00.002571)

 print sql_query

 - SELECT  run.date, x_wind.validity, m_pow.power, x_wind.power,
 x_wind.run FROM source, fc_model, run, x_temp, site, meta_data, x_wind
 LEFT JOIN m_pow ON ((x_wind.validity = m_pow.validity) AND (x_wind.site
 = m_pow.site)) WHERE ((x_wind.validity = x_temp.validity) AND
 (x_wind.site = x_temp.site)) AND (x_wind.run = x_temp.run)) AND
 (x_wind.source = x_temp.source)) AND (x_wind.site = site.id)) AND
 (x_wind.run = run.id)) AND (x_wind.source = source.id)) AND
 (source.model = fc_model.id)) AND (x_wind.meta_data = meta_data.id)) AND
 (x_wind.validity = '2010-11-30 23:00:00') AND (x_wind.validity 
 '2010-12-08 22:59:00')) AND (x_wind.source IN (2))) AND
 (x_wind.meta_data IN (1))) AND (x_wind.site IN (1 ORDER BY
 x_wind.meta_data, x_wind.run, x_wind.source, x_wind.site,
 x_wind.validity; (second try query not reported)

 t0 = datetime.datetime.today()
 prova = db.executesql(sql_query)
 print len(prova)

 - 576 (second try: 1080)

 print 'query executed via raw mysql: ', datetime.datetime.today() - t0

 - query executed via raw mysql:  0:00:07.264365 (second try: query
 executed via raw mysql:  0:00:13.251476)

 t0 = datetime.datetime.today()
 data_source = db(join  where).select(*what, left=left_join, orderby=order)
 print 'query executed via DAL ', datetime.datetime.today() - t0

 - query executed via DAL  0:03:23.115262 (second try: query executed
 via DAL  0:12:19.628098)

 Is there something wrong in the usage of the DAL query?

 thank you very mutch in advance

 Cheers

         Manuele


Re: [web2py] Re: what's up in DAL?

2011-06-14 Thread Manuele Pesenti

On 14/06/2011 15:12, Massimo Di Pierro wrote:

How many records does it return?


192 in the first case and 360 in the second
this is a tipical row extracted converted in csv:

2010-11-29;2010-12-01 01:00:00;4368.96;4854.3;60

so there's one date, one datetime, two float and one integer

how can I made it more usable? Do I have to limit someway the query?

thaks a lot

Manuele



There is a difference. If you execute the query using DAL, web2py
loops over the output and converts the raw output into a database
independent formatting (for example if the database returns a date as
a string, web2py converts that into a datatime.date object) and store
them into a Storage object.


There is no overhead in generating the query from DAL but there is
overhead in normalizing the output.

This is necessary because every database engine will return records in
a different format but web2py needs to make the response database
independent.

If you run with profiler you will find that most of the time is spend
in the function parse.





Re: [web2py] Re: what's up in DAL?

2011-06-14 Thread Manuele Pesenti

On 14/06/2011 15:47, Manuele Pesenti wrote:

192 in the first case and 360 in the second


errata corrige:

576 and 1080

as eaplained in the previous email

M.


Re: [web2py] Re: what's up in DAL?

2011-06-14 Thread Martín Mulone
did you tried with limitby ?.

2011/6/14 Manuele Pesenti manuele.pese...@gmail.com

 On 14/06/2011 15:58, Manuele Pesenti wrote:


 errata corrige:

 576 and 1080

 as eaplained in the previous email

 M.


 I'm very sorry about so many posts on the same thread... but I have to
 notice one thing... what executesql returns is a tuple like that:

 ((datetime.date(2010, 11, 28), datetime.datetime(2010, 11, 30, 23, 0),
 None, 8997.60004, 59L), (datetime.date(2010, 11, 29),
 datetime.datetime(2010, 11, 30, 23, 0), None, 6209.39996, 60L), ...
 )

 so the normalization of the fields is included in the first 13 seconds...
 so what's up in the subsequent 12 minutes? I thik the transformation in a
 Rows like object...


M.




-- 
 http://martin.tecnodoc.com.ar


Re: [web2py] Re: what's up in DAL?

2011-06-14 Thread ron_m
Are you returning enough data to cause the system to go into paging - check 
the system monitoring tools, not sure what you are running on, to see if 
there is a large amount of VM activity involving paging to disk while this 
is running. That would really kill performance. The entire data returned by 
the query will be turned into a Rows object so it all has to live in memory 
at the same time.

Another odd clue is the second time takes longer than the first time. 
Normally it should take less time because the caching in the system such as 
in the database engine is warmed up. If VM activity is high, caching will be 
defeated because those assumed high speed memory caches saved in case the 
are needed again in a short time might have been rolled out onto the disk.

Ron