New Timesheed extrem slow egw 16.9.002

[Cheese68]

I have a problem while entering a new timesheed (Stundenzettel) for a project with many timesheed entrys. It takes up to 120 sec for each new entry.
The timesheed app is configured for using the projectmanager conpletely (complete: use projectmanager only)
I did a sql log and looked for slow querys, but I was surprised to find a whole bunch of update statement tying to update every single timesheed (title) entry for the given project.

I think this is a bug. Is it already known/solved?

greeting from Kiel
Andreas

[StefanU]

Hello Andreas,

is the problem new (due to an update) or did the problem develop over a longer period of time?

Greetings
Stefan

[Cheese68]

The problem is occurs every time I enter a new timesheed for a project with many timesheed entrys.

SQL Log looks like
"2017-11-07 15:54:35";“egroupware[egroupware] @ localhost [127.0.0.1]”;“209”;“1”;“Query”;"SELECT * FROM egw_timesheet WHERE ts_id=18288"
“2017-11-07 15:54:35”;“egroupware[egroupware] @ localhost [127.0.0.1]”;“209”;“1”;“Query”;“SELECT * FROM egw_links WHERE ((link_app1=‘timesheet’ AND link_id1=‘18288’) OR (link_app2=‘timesheet’ AND link_id2=‘18288’)) AND deleted IS NULL ORDER BY link_lastmod DESC”
“2017-11-07 15:54:35”;“egroupware[egroupware] @ localhost [127.0.0.1]”;“209”;“1”;“Query”;“UPDATE egw_timesheet SET ts_project=‘B-2017/1002: Xxxxxxxxxx’ WHERE ts_id=18288”

… repeating 1000 times for different ids

“2017-11-07 15:52:40”;“egroupware[egroupware] @ localhost [127.0.0.1]”;“209”;“1”;“Query”;"SELECT * FROM egw_timesheet WHERE ts_id=21466"
“2017-11-07 15:52:40”;“egroupware[egroupware] @ localhost [127.0.0.1]”;“209”;“1”;“Query”;“SELECT * FROM egw_links WHERE ((link_app1=‘timesheet’ AND link_id1=‘21466’) OR (link_app2=‘timesheet’ AND link_id2=‘21466’)) AND deleted IS NULL ORDER BY link_lastmod DESC”
“2017-11-07 15:52:40”;“egroupware[egroupware] @ localhost [127.0.0.1]”;“209”;“1”;“Query”;“UPDATE egw_timesheet SET ts_project=‘B-2017/1002: Xxxxxxxxxx’ WHERE ts_id=21466”

[StefanU]

Hello Andreas,

I don’t understand it that way.
In another topic, a user reports that with 17.1 it works much faster in this area.
Would it be possible for you to make a update test to 17.1?

Greetings
Stefan

[StefanU]

Hello Andreas,

could you do a test?

Greetings
Stefan

[Cheese68]

Sorry for my late replay.
I did an Update to 17.1, but it did not solve the problem.

[Cheese68]

The problem became even worse. I turned on MySql logging and found a hole bunsh of unesserary updates, as mentioned above.
After commenting out the this->update statement in line 962 of class.timesheed_bo.inc.php (function notify($data) )
I’m able again to enter new timesheeds.