On 4/17/07, Christian Rost <[EMAIL PROTECTED]> wrote:
Dave Hall schrieb: > On Tue, 2007-04-17 at 15:26 +0200, Christian Rost wrote: >> Johan Gunnarsson schrieb: >>> Hi, >>> >>> Thanks for your input. My project is supposed to be a native PHP >>> implementation, but I'm of course open for discussions. I know some >>> Java so switching to making a connector for Funambol is an option >>> worth dicussing. > > The final implementation is not set in concrete, but I think that the > php native implementation is more likely to succeed and be maintainable > within the project with our own resources. > That's right and again, I'd like to help as much as possible because I'm really interested in this feature.
Great. Stick around this summer and watch me progress with the work :-)
>> Yeah, it is a beast to configure and it consumes a lot of RAM. During an initial sync it takes >> up to 600 MB and unfortunately doesn't give it back when the sync is done. Because we don't know >> much Java, we couldn't get a hold on it wether it's the server or the connector that consumes so >> much RAM. But that's a problem you could easily deal with by buing more RAM. >> > > 600M for a sync? that is insane. You could easily DoS a box by running > a couple of syncs. > No, the server isn't going to DoS the box. It only consumes up to 600 MB RAM for an initial sync of 4000 contacts and stays with it. Even with multiple syncs it doesn't take more than that - oh btw we didn't try to start several ininital syncs at the same time, yet. But one initial and a bunch of follow up syncs work quite well together. Currently there are up to 20 users syncing their Blackberry via Outlook and some Pocket PC 2003/2005/2005 Phone Ed. users. If if gets crowded, there are up to 3 concurrent syncs at the same time, but mostly it's only one users syncing his/ her device. Resource allocation is quite an interesting topic that comes with the Sync. We to raised the session timeout to 3 hours to handle the worst case - slow box and a maximum amount of sync items - and some other PHP related settings like max_execution_time, max_input_time, memory_limit as well.
2 seconds per item really sucks. But I guess it's not much to do about it as long as the blackberry/pda is the bottleneck. Still I can't really think of any reason why this takes so much time. I mean, It's mostly just about moving data around.
>> Another problem is speed. SyncML is based on HTTP and therefore not an time critical protocol, >> but the clients could have build in timeouts. If you're running phpGroupWare with e.g. MySQL it >> is much faster than with the additional LDAP backend. Because LDAP lookups take much longer than >> SQL queries, you have to keep it in mind when checking ACLs. As usual, if we're talking about a >> small amount of items to sync, let's start with contacts and appointments, it doesn't matter if >> it takes 5 or 15 milliseconds per lookup but it adds up to a quite a lot of time with at least >> several hundreds or thousands items. >> > > Optimising and caching to improve performance is not something Johan > will be expected to work on, but it is something that I will be trying > to spend some time on as he identifies problems. > Caching and code optimization are the key words. E.g. we use the LDAP-backend for users and group information and discovered that infolog needed up to 20 secs for loading with about 300 LDAP users. The reason was an UIDNumber query for each entry. While an SQL-query takes only some milliseconds, an LDAP-query needs up to a second. We disabled the stupid query, cecause the UIDNumber was already available and infolog became app. 5 times faster than before. Christian -- =========================================================== Christian Rost roCon - Informationstechnologie Glatzer Weg 4 44534 Lünen fon: +49 (0) 2306 910 658 fax: +49 (0) 2306 910 664 url: http://www.rocon-it.de _______________________________________________ phpGroupWare-developers mailing list [email protected] http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
_______________________________________________ phpGroupWare-developers mailing list [email protected] http://lists.gnu.org/mailman/listinfo/phpgroupware-developers
