Re: [phpGroupWare-developers] Google Summer of Code

[Johan Gunnarsson]

On 4/17/07, Christian Rost <address@hidden> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/phpgroupware-developers