[horde] horde/imp migration problems, cpu bound on solaris

[Vasilios Hoffman]

> Try a php accelerator.  Also mcrypt in php.  Both of these were already
> mentioned.  If you have lots of mail boxes (you don't say how many mailboxes
> you serve) you might be able to do some kernel tuning to cache more inodes
> and files in memory...

I'm going to try the php accelerator & mcrypt actually, and will let folks
know.

> Are you sure the "seconds to execute" isn't really in the imap connection
> and authentication, rather than in the php/horde software?

Yes, I've timed that, both by hand (telnet localhost 143 and "speaking"
imap -- horde makes a localhost connection.  I've also tried it with the
imapproxy) and by digging into the code and logging what was going on with
imap.  Basically, enough to know fairly certainly that imap is okay.  The
current imp is also using the same imap server and not having the problem.

>
> No.

Thank god :)

> > Is this the performance everybody else is getting?
>
> No.

Alleluia! or however you spell that.

> It isn't Horde, unless you do things on the summary page and so on to slow
> it down.

nope

> It could be php, it could be apache, it could be your mail server, it
> could be a firewall, etc.  You've really not told us enough to know for
> sure.

my apologies, I wanted the email to be short enough to be paid attention
to.  I have found that if I exauhstively (sp?) list everything I have
done,  it drags on and nobody understands my point nor replies to it.
Perhaps I'm wrong, but that's just my experience.  I found it was
processor bound, and having trouble with the php code -- not imap, not
memory, not I/O.  I tried to communicate that, and hoped folks would take
it at face value.  If I'm wrong, I'll eat my shorts and share it with the
list :)

I also didn't want to spend all day profiling it and seeing
where the slowdowns were in the code, not without checking to see if I
missed anything foolish -- hence the short synopsis.

I will try mcrypt and php accelerator, and get back to everybody!  I
really appreciate the feedback.

> You really need to isolate where the major slowness is.  How long, for
> example, does a page that doesn't use the imap server run compared to
> one that does use the imap server?  That can help answer if the imap
> server is part of the problem or not...  If you connect via a local
> web browser on the loopback device is it slower/faster than a remote
> browser over the network?  If so, your network may be slow...
> Simple tests like that will go a long way to finding out where the
> problems/slowness is really at.

Again, most of these variables are ruled out because the machine is
currently in use, running imp, and running it well enough.  I know the
network is fined, switched 100base-T and the switches are not at max.  the
imap is used by the old imp, and I've tested it otherwise, and the only
thing left with imap that's plausible is some software bug between this
version of php and this version of imap, but I've tried the old imap and
another version of php and can rule that out enough to satisfy me.

Sorry, I didn't want to bore everybody listing everything I did!  We also
use this software (apache, mod_ssl, etc) in dozens of places and don't
have problems with it, I'm familiar enough with the setup and the
variables to say with fair certainty that it is the php processing time
that is dogging it.  (Oh, the database is fast enough too, I checked
that).

Thanks!  If anybody has php.ini suggestions or other tracks I'll follow
those, otherwise I'll be back in a bit with mcrypt/php accelerator
results.

-V