phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Phpgroupware-developers] Performance tests


From: Markus Kaemmerer
Subject: [Phpgroupware-developers] Performance tests
Date: Fri, 27 Feb 2004 11:32:41 +0100

Hi,

today I made some tests regarding performance of phpGW. 

For the synchronization we need address data. For a quick start I
wrote a little script to fetch 200 times the same contact (click on
view in address list). I used wget to simulate a real click on this
button. I used the same session (php4 and db sessions did not make a
difference in performance) on my 1.6 GHz Pentium M with Apache 1.3.29,
PHP 4.3.4, mmcache and MySQL 4.0. Without mmcache the test was about
two times slower, but the relative values where the same.

phpGW created about 1.4 MB of HTML data for the 200 views. On my
notebook this took about 44 seconds, leading to 220ms for one view
without rendering the HTML output. In other tests I found that
fetching a vCard from the addressbook internally took about 45-50ms. 

I changed some internal behaviors but could not found any major
difference. I disabled caching of address data in sessions variables,
this improved the performance about 5 percent. But this is not a major
difference. I suggest to remove the cache handling and let the
database do this thing. This removes complexity from the code and
leads to a very little speed up.

To have a comparison value I fetched 200 times the month view from an
empty calendar. This took about 63 seconds, about 315ms per view. In
this test phpGW created about 10 times more HTML data [14 MB] than in
first test. 

I think most time is consumed during the context switches and for
initialization of all internal variables etc. in the phpGW API. I
think it should be possible to do a little work here to reduce the
initialization overhead as far as possible. This would improve the
subjective and objective performance on every single click to phpGW
because the user has to wait at least 0,2 seconds before the selected
application starts to create and send HTML code. Remember, that I used
a fast notebook with local database, mmcache and only one user. On
larger installations this overhead would result in longer response
times.

Every speed up on this would also improve synchronization speed,
because we have to make at least one (XML-RPC) call for every
synchronized item.

Markus

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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]