[Tickets #4882] IMSP backend - speedup browse with many groups

bugs@bugs.horde.org bugs at bugs.horde.org
Fri Jan 12 11:48:15 PST 2007


DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=4882
-----------------------------------------------------------------------
 Ticket             | 4882
 Created By         | noah at lsit.ucsb.edu
 Summary            | IMSP backend - speedup browse with many groups
 Queue              | Turba
 Version            | HEAD
 Type               | Enhancement
 State              | New
 Priority           | 1. Low
 Owners             | 
+New Attachment     | turba-imsp-group-optimizations.patch
-----------------------------------------------------------------------


noah at lsit.ucsb.edu (2007-01-12 11:48) wrote:

For the reasons discussed in Ticket 855, essentially that everything is
loaded and filtered "client-side" (php layer) when browsing, some kind of
speedup strategy is needed. In particular, the way Turba reads Groups
seems very inefficient when loading everything for browsing. It ends up
searching and fetching each email address  in the Group, even though it's
also searching and fetching those contacts just as a part of the address
book being browsed.

Here's a strategy to reduce some of the redundant IMSP fetching: 
1. _search sends all ids in the addressbook to _read. (As per Ticket
4881)
2. While stepping through the id list, if a Group is encountered, push the
group's id to the end of the list (we'll handle Groups when all contacts
have been loaded).
3. Because the Group had to be read to be identified as a group, it is
stored temporarily before proceeding.
4. After all contacts are loaded, the Groups are processed. Each group is
loaded from the temporary array at this point, then it looks through the
existing contact results for a match instead of going back to the IMSP
server. If no result is found, it falls back to searching the IMSP
server.

NOTE: This strategy requires the patches from Ticket 4881, as all the
optimizations take place in the _read function.




More information about the bugs mailing list