Re: [phpGroupWare-developers] Google Summer of Code

[Christian Rost]

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.


>> 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.


>> 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