Re: [Phpgroupware-developers] Performance tests

[Markus Kaemmerer]

Alex Borges <address@hidden> wrote:,

>This is a great way to test. We do it with elsa for massive testing.
>Let me get this straight,  you hit on the uiaddressbook.view  method
>right?

Right.

>Good news is that yeah, the mmcache does make a huge difference. 

mmcache helps really a lot, but can not fix some design issues left.

>A question now is if its actually taking all of 15 minutes (more than 3-5
>is already hard to accept  for a user though) to sync 300 contacts as in
>your previous test.

Because there are many calls to phpGW during a sync session this
counts up. Every bit of reduced sync overhead would reduce sync time
and improve application response times for _all_ modules.

>Ok, one thing.... did you try with php4 sessions or db sessions?

I tried both, no real difference.

>This is a good baseline and shows how much faster it could be. Still,
>the complexity difference of the tables (thus the sql) is also in about
>the same order (9 table, pretty complex design vs 4 table, quite
>straightforward design). Still, yeah, i think its time to do some
>performance code audit. We will get to that soon (first correct
>addressbook, worry about fast addressbook later)

The count of tables should not be a problem. If they are correctly
connected through relations and indizi, the database can handle it
really fast. As my tests show, the database itself is not the
performance killer as we could think (assumed correct database design
and use of index fields).

>Naturally. For example, 14 with 1800, multiuser, direct hits to the
>email app can render a 2 minute latency time for users. I agree that
>there is a lot of room for performance fixing. 

If we want to use phpGW in larger installations, we have no other
chance than doing some performance fixing. 

>In the speciffic of the addressbook. Well, its a very complex thing
>there. It loads all the sql_entity classes, the sql_builder, the
>contacts_sql and addressbook bo/so/ui classes. 

Loading does not (much) take time with a cache like mmcache. So there
is no problem with large modules. 

>Yes.. As ive said, xml-rpc is an interesting chalenge precisely because
>it is an RPC protocol. This means that its a pagehit for every function
>called (them being add vcard, remove vcard or whatever).

Correct. It is the same if the user hits any link in his module. Every
time we have a page hit and have to do initialization from the whole
beginning.

>In this line... perhaps we can change it so that the xml-rpc sync sends
>a list of vcards, and we can sync the list in bulk instead of going one
>by one? Then make a protocol for conflict handling on this basis?

This would throw the initialization overead to nearly null, correct.
But this would force us to do a major redesign of Sync4j. This time
can be better used to improve phpGW speed for all applications.

>> P.S. To bring some good news, too: we managed to synchronize our test
>> devices (PocketPC, Calmeno Outlook Plugin, P800 and a Nokia handy via
>> GPRS) in both directions including add and delete. I'll publish more
>> information and code in the next few days.
>
>This is GREAT news! BTW. some of us are eager to look at the sync app,
>ive the feeling you have an internall one that actually works (current
>one does not work in postgres). Please commit it into head!

Did you fix the postgress problem? I wrote an email regarding this
yesterday.

Markus

--
Markus Kämmerer         Team Software Solutions
pro|business AG, EXPO Plaza 1, 30539 Hannover
E-Mail: address@hidden,  Phone.: 0511/60066-0
WWW: http://www.probusiness.de/,    Mobile: 0177/5990932

**********************************************
           address@hidden 2004

*       Halle 1, Stand 3k4 (Magirus Deutschland GmbH)
*       Halle 1, Stand 7f2 (EMC Deutschland GmbH)
*       Halle 6, Stand D46 (Land Niedersachsen)
**********************************************