Re: [Phpgroupware-users] PHPGroupware optimization [mysql, ldap]

[Dave Hall]

Hi Christian,

My comments are inline.

On Sat, 2005-10-29 at 09:15 +0000, Christian Rost wrote:
> Hi Dave,
> 
> we checked out some further details and are pretty sure that it's a coding
> issue. As mentioned before, MySQL and slapd have enough performace to cope
> with the queries and aren't the bottleneck in this case. Even memory shouldn't
> be an issue.
> 
> Oh, BTW the system we're talking about is our test-system with 512MB RAM, a
> 2GHz Celeron and two ATA 133 HDs. We copied the production system to our
> test-system to get the software configuration and data of our customer.
> 

Those are good enough specs for what you are talking about.

> We started apache2 with several spare servers to increase response time and
> speed, but that doesn't got us further, if the process used for calling
> Infolog takes up to 20 secs and causes 80%- 90% CPU load. Calendar and
> Addressbook work quite fine.
> 

Spare severs don't give a huge boost to response times on smaller
installs.  I find it strange that cal performs ok.  The install where a
client of mine had issues was 3k users and lots of groups, a little
bigger than your install, but this was crippling their dual Xeon box.

> During the 20 second we need to start InfoLog, there's a bunch of LDAP queries
> for the uidNumber of the user and the gidNumbers of all groups the user
> belongs to within phpgw. These queries take about 1-2 secs.
> 

LDAP queries are expensive.  But they shouldn't be that expensive.  Can
you enable slapd to log all ldap queries and their results, before
starting infolog and send me the output off list? iirc loglevel 32
should do it (or maybe it is 16), sorry its been a while since I have
had to do heavy ldap query debgging.

> For the next app. 15 secs PHPgw queries LDAP for for all uidNumbers and
> gidNumbers (uidNumber=*) every 2 to 3 secs.
> Finally the queries from the beginning are repeated again.
> 

I would like to see what it is looking for.

> Because of this behavior, we're quite sure that the performance issue is
> caused by the processing of data within the Infolog scripts. In addition, an
> accelerator cache like turk-mmcache, didn't get it any faster. The Infolog
> scripts are cached, but the scripts itselfes take too much time.

Infolog's design is all arse about which makes it a real pita to go bug
hunting in.

Before I volunteer to go bug hunting I would like to see what the
queries are it is running and what the results are.  btw what if any
mods have you made to infolog?

I wish I had a simple change this solution, but I don't :(

Cheers

Dave