c2c-oerpscenario team mailing list archive

["Guewen Baconnier @ Camptocamp" <798732@xxxxxxxxxxxxxxxxxx>]

Hello Fabien,

You changed the status to Fix Released put I cannot see the changes on the
branch, it doesn't seems to be merged. Can you check please ?

Thank you!
Guewen
Le 11 nov. 2011 15:35, "Fabien (Open ERP)" <fp@xxxxxxxxxxx> a écrit :

> ** Changed in: openobject-addons
>       Status: Fix Committed => Fix Released
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/798732
>
> Title:
>  hr_timesheet_sheet: Timesheets  big performance issues
>
> Status in OpenERP Addons (modules):
>  Fix Released
>
> Bug description:
>  Hello,
>
>  We are experiencing major problems of performance on timesheets.
>  OpenERP 6.0.2
>  Performance issues occur with the module hr_timesheet_sheet.
>
>  We have ~ lines per tables :
>   - hr_timesheet_sheet : 7'500
>   - hr_analytic_timesheet : 110'000
>   - hr_attendance : 110'000
>
>  Opening the "Timesheets" menu takes a few minutes for the 80 first rows.
>  Then open the timesheet form view takes nearly 30 seconds.
>  Each action on a timesheet (Sign-in/out, fill a timesheet line, ..) takes
> nearly 30 seconds again.
>
>  It's clear that the main cause of the problem is : hr_timesheet.sheet.day
>  This view computes the indicators for the whole tables and only
> afterwards we get the rows that we need.
>
>  The second cause of the problem is the fields sheet_id in
>  hr.attendance and hr.analytic.timesheet which are function fields.
>
>  The function fields total_attendance_day, total_timesheet_day,
>  total_difference_day, total_attendance, total_timesheet,
>  total_difference of hr_timesheet_sheet.sheet are based on this view,
>  so that's why each action on the timesheet take 30 seconds, because
>  the view is computed again and again.
>
>  Here is the actions that I found to bring an acceptable situation:
>   - Removed the "By Day" page on the timesheet view, instead I added a
> link which open a new view (this will still be slow but it can be
> acceptable as a first solution as you decide to open it...).
>   - I replaced the methods to compute the hr_timesheet_sheet.sheet
> function fields by full python instead of a cr.execute() on the view.
>   - There is still a bottleneck, on a search of sheet_id in hr.attendance
> and hr.analytic.timesheet, it executes each time a sql query. I added
> store=True to the function field. The only issue I see with that is in the
> case of a modification of the employee_id of the timesheet, we can add a
> trigger on this modification, but I don't see how we can search lines to
> update. What are your thoughts ? (Is it useful to change the employee of a
> timesheet after its creation, can we block this ?)
>
>  This improves a lot the performances, but there is still a lot of room
>  to improve them !
>
>  Maybe we have to replace this function fields / one2many_mod with
>  one2many fields ?
>
>  Here is the link to my branch (I propose a merge.)
>
> https://code.launchpad.net/~gbaconnier-c2c/openobject-addons/6.0-hr_timesheet_sheet-performance-improvements
>
>  Thanks
>  Guewen
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/798732/+subscriptions
>

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to OpenERP Project Group.
https://bugs.launchpad.net/bugs/798732

Title:
  hr_timesheet_sheet: Timesheets  big performance issues

Status in OpenERP Addons (modules):
  Fix Released

Bug description:
  Hello,

  We are experiencing major problems of performance on timesheets.
  OpenERP 6.0.2
  Performance issues occur with the module hr_timesheet_sheet.

  We have ~ lines per tables :
   - hr_timesheet_sheet : 7'500
   - hr_analytic_timesheet : 110'000
   - hr_attendance : 110'000

  Opening the "Timesheets" menu takes a few minutes for the 80 first rows.
  Then open the timesheet form view takes nearly 30 seconds.
  Each action on a timesheet (Sign-in/out, fill a timesheet line, ..) takes nearly 30 seconds again.

  It's clear that the main cause of the problem is : hr_timesheet.sheet.day
  This view computes the indicators for the whole tables and only afterwards we get the rows that we need.

  The second cause of the problem is the fields sheet_id in
  hr.attendance and hr.analytic.timesheet which are function fields.

  The function fields total_attendance_day, total_timesheet_day,
  total_difference_day, total_attendance, total_timesheet,
  total_difference of hr_timesheet_sheet.sheet are based on this view,
  so that's why each action on the timesheet take 30 seconds, because
  the view is computed again and again.

  Here is the actions that I found to bring an acceptable situation:
   - Removed the "By Day" page on the timesheet view, instead I added a link which open a new view (this will still be slow but it can be acceptable as a first solution as you decide to open it...).
   - I replaced the methods to compute the hr_timesheet_sheet.sheet function fields by full python instead of a cr.execute() on the view.
   - There is still a bottleneck, on a search of sheet_id in hr.attendance and hr.analytic.timesheet, it executes each time a sql query. I added store=True to the function field. The only issue I see with that is in the case of a modification of the employee_id of the timesheet, we can add a trigger on this modification, but I don't see how we can search lines to update. What are your thoughts ? (Is it useful to change the employee of a timesheet after its creation, can we block this ?)

  This improves a lot the performances, but there is still a lot of room
  to improve them !

  Maybe we have to replace this function fields / one2many_mod with
  one2many fields ?

  Here is the link to my branch (I propose a merge.)
  https://code.launchpad.net/~gbaconnier-c2c/openobject-addons/6.0-hr_timesheet_sheet-performance-improvements

  Thanks
  Guewen

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/798732/+subscriptions