Tickets :: [#2900] Listing a large number of shares takes a long time

6.0.0-RC7

6/27/26

History
Attachments
Comment
Watch
Download

Summary	Listing a large number of shares takes a long time
Queue	Horde Framework Packages
Queue Version	HEAD
Type	Bug
State	Duplicate
Priority	1. Low
Owners	Horde Developers (at)
Requester	frank.richter (at) hrz (dot) tu-chemnitz (dot) de
Created	11/2/05 (7542 days ago)
Due
Updated	5/18/06 (7345 days ago)
Assigned	11/9/05 (7535 days ago)
Resolved	5/18/06 (7345 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

13	Chuck Hagenbuch	Comment #15 State ⇒ Duplicate	Reply to this comment
Marking this as a duplicate of ~~bug 3126~~. Any objections?

557	Chuck Hagenbuch	Summary ⇒ Listing a large number of shares takes a long time

347	Chuck Hagenbuch	Comment #14 Queue ⇒ Horde Framework Packages State ⇒ Version ⇒ HEAD	Reply to this comment
Seems like a more accurate reflection of what's going on here - any disagreement?

2410	Jan Schneider	Comment #13	Reply to this comment
Nothing yet. We need to dive into the code to see where we can optimize it.

599	Chuck Hagenbuch	Comment #12	Reply to this comment
Jan, what did you see as the course of action here?

588	Jan Schneider	Assigned to Horde Developers State ⇒ Assigned

247	frank (dot) richter (at) hrz (dot) tu-chemnitz (dot) de	Comment #11 New Attachment: log.txt	Reply to this comment
Ok, unique lines, and the counts.

13	Jan Schneider	Comment #10	Reply to this comment
Are you interested in it? Not completely, but maybe you could upload a few typical lines.

421	frank (dot) richter (at) hrz (dot) tu-chemnitz (dot) de	Comment #9	Reply to this comment
I've deleted these entries ... well it doesn't help. Whenever $this->_calendars = $shares->listAllShares(); is called, it takes between 25 and 40 minutes to complete. I've run the reminder script with debug_level E_ALL. It produced a 5.5 MB log file (8683 lines of SQL queries). Are you interested in it?

369	Jan Schneider	Comment #8	Reply to this comment
Yes.

349	frank (dot) richter (at) hrz (dot) tu-chemnitz (dot) de	Comment #7	Reply to this comment
IMP related history data ..., is it delete from horde_datatree where group_uid='horde.history' and datatree_name like "imp.%" (18954 entries)?

1610	Jan Schneider	Comment #6 State ⇒ Not A Bug	Reply to this comment
This is a lot. Disable message history in IMP's configuration and delete all history entries for IMP, or wait for the new History library from Horde 3.1.

4412	frank (dot) richter (at) hrz (dot) tu-chemnitz (dot) de	Comment #5	Reply to this comment
select count(*) from horde_datatree where group_uid='horde.history' \| 30085 \|

1011	Jan Schneider	Comment #4	Reply to this comment
Take a look at your horde_datatree table, does it have a lot of entries with a group_uid of 'horde.history'?

89	frank (dot) richter (at) hrz (dot) tu-chemnitz (dot) de	Comment #3	Reply to this comment
I detected two different situations: 1. It runs about 20 seconds: 10:30:05 /var/www/html/horde/kronolith/lib/Scheduler/kronolith.php: 59 10:30:05 /var/www/html/horde/kronolith/lib/Scheduler/kronolith.php: 77 10:30:05 /var/www/html/horde/kronolith/lib/Scheduler/kronolith.php: 85 before Kronolith::listAlarms 10:30:24 /var/www/html/horde/kronolith/lib/Scheduler/kronolith.php: 87 after Kronolith::listAlarms 10:30:24 /var/www/html/horde/kronolith/scripts/reminders.php: 62 2. It goes through listAllShares(), and this takes quite long! 09:55:21 /var/www/html/horde/kronolith/lib/Scheduler/kronolith.php: 59 09:55:21 /var/www/html/horde/kronolith/lib/Scheduler/kronolith.php: 68 before listAllShares 10:27:36 /var/www/html/horde/kronolith/lib/Scheduler/kronolith.php: 71 after listAllShares 10:27:36 /var/www/html/horde/kronolith/lib/Scheduler/kronolith.php: 77 10:27:36 /var/www/html/horde/kronolith/lib/Scheduler/kronolith.php: 85 before Kronolith::listAlarms 10:28:34 /var/www/html/horde/kronolith/lib/Scheduler/kronolith.php: 87 after Kronolith::listAlarms I have two "public" calendars, readable by anyone (but no alarms in it). Hope that helps to help, Frank

910	Jan Schneider	Comment #2 State ⇒ Feedback	Reply to this comment
Set logging to debug level, and add "echo"s and "var_dump"s in the code of lib/Scheduler/kronolith.php to see where it takes so long.

221	frank (dot) richter (at) hrz (dot) tu-chemnitz (dot) de	Comment #1 Priority ⇒ 1. Low State ⇒ Unconfirmed Queue ⇒ Kronolith Summary ⇒ reminders.php runs very long Type ⇒ Bug	Reply to this comment
Hi, I've set up reminder functionality according to http://wiki.horde.org/KronolithReminders Every 15 minutes cron starts as user root /usr/bin/php -q /var/www/html/horde/kronolith/scripts/reminders.php The script runs VERY long, over 40 minutes (on our busy production machine). Currently I don't use this script. I assume there must be something wrong. Can I debug this script? We have 11749 registered users (horde_prefs), but 130 users with 1238 events in kronolith_events table only. Thanks, Frank