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

* Your Email Address
* Spam protection	Enter the letters below: .__ .. ..__ . . [ __ \|\ /[ __\| \| [_./\__\| \/ [_./\|/\\|
Comment	>> 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.
Attachment
Watch this ticket

Saved Queries