[Tickets #6556] Re: Large IMSP books/groups slow every page request

[bugs at horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/6556
-----------------------------------------------------------------------
 Ticket             | 6556
 Updated By         | noah at lsit.ucsb.edu
 Summary            | Large IMSP books/groups slow every page request
 Queue              | Turba
 Version            | HEAD
 Type               | Enhancement
 State              | Feedback
 Priority           | 1. Low
 Milestone          |
 Patch              | 1
 Owners             | Michael Rubinsky
-----------------------------------------------------------------------


noah at lsit.ucsb.edu (2008-04-09 17:22) wrote:

> FWIW, this is only 100% accurate for entries added by Turba...and is
> absolutely not accurate for at least two other IMSP clients that I
> have used - although it has been some time since I've looked at it.

It seems you are right. At least part of that is my inflexible regex.
Changing the regex gives some better results:
/(?:^(.*)\s*<)?(\w[-._\w]*\w@\w[-._\w]*\w\.\w{2,3})/ is better than
/(?:^(.*)\W<)?(\w[-._\w]*\w@\w[-._\w]*\w\.\w{2,3})/

It seems many clients don't include the space between the name and the
<email>.

When you say that it is "absolutely not accurate for at least two IMSP
clients," do you mean that it produces inaccurate results, or that it does
not produce results for those clients?  We are using a combination of Turba
and Mulberry as IMSP clients, and the improved regex catches a good number
of groups created by Mulberry.

I've seen it miss on various inputs, but I've not seen it produce actual
inaccurate results.

> I fixed this by only hitting that code when we actually *want* to
> populate the __members property.  This should also help in other
> places as well, like when browsing the address book.
>
> I don't currently have an IMSP server handy to test this, so please
> let me know how this works out.

Your alterations work fine. Performance was enhanced somewhat. It's
definitely a good approach.

I have a couple other patches that drastically increase performance by
adding a getEntries function to the framework Net/IMSP/Book.php file. It
does one FETCHADDRESS command per some maximum batch size (I'm using 220).
This reduced request times for browsing address books with over 600 entries
from minutes (or timeout) to ~10 seconds. I had to also patch Turba's
lib/Driver/imsp.php file w/ a _readBatch function that's highly similar to
_read, and probably could be folded into it by someone with a tiny bit more
time and turba knowledge (I changed _read to call _readBatch if more than a
certain number of names are passed to it).

My questions are, is it worth submitting my patches, and what's the
protocol for submitting bugs and patches against multiple projects (in this
case Framework & Turba)? Would I open separate bugs, one for the IMSP lib
and one for Turba? If you think they're worth submitting, should I add them
to this bug, or open a fresh one?

Thanks.