Thank you, Andreas, I see some interesting points there.
The following remarks are not only for Andreas, but contain some more
questions for other readers, too. ;-)
There are some "bells-and-whistels" in the new version which can
kill your performance..
Some suspect settings
- message preview
Yes, I have read about this and have seen it myself in my own test. I
had even a particular single message which alone caused a huge delay
when displaying the mailbox list. But this is more a thing to watch
out in the future. As this is a new user option which has to be
explicitly activated it cannot be involved in my initial problems.
- message sort
I remember a discussion here that there can be a problem with certain
(also new) sort options. Anybody can help me what these were exactly?
- spell check
I think, this is not much used here.
But annother candidate in this category could also be the new
autocomplete in the address input fields. I do not see an option to
deactivate it, and it certainly creates more database traffic.
And database traffic in general: During my unintended "public
performance test" I had a situation where database connection were not
all accepted by our MySQL server and I saw many warnings/errors in the
imp log with the names of the new groupware components which we had
not in use before. I got the impression that these program parts
create a lot of background activity even when they are not really used.
- not using the cache settings
Hmm, I actually have this new option deactivated currently.
During my tests I had it active first (with local file storage) but
after a while the system came in a state where it did no longer
displayed things correctly. This issue disappeared again with
deactivated horde cache. So for the moment I have not yet much
confidence in this caching. I mean there was also recently a
discussion here that there are known errors in this caching code which
will only be corrected in the next imp generation. Anybody can shed
more light on this?
If it works, I think using the recommended memcache system would help here.
In my situation I have enough RAM available for storing everything
possible into RAM (all our web servers run on VMware systems). More
CPUs would cause additional costs (for a Redhat Server license) but
would also be possible if I find out that they help.
- using maillog with high mail volume
Yes, but that's a feature that we want to use, it will help us
detecting cases of abuse (automated sending of spams).
What is needed at PHP level
- a opcode cache like APC
This seems to be the single most given recommendation for PHP
applications, I will certainly try it out. It should mainly reduce CPU
usage?
- mcrypt support
On board.
Also check that all the index settings in the database are correct.
What do you mean with correct, what could I do/check here?
As the old database was no longer usable with the new version (e.g.
different field names, different character codes) I had first
installed a completely new database with the scripts from the current
versions. Later on I have transferred the contents of our old DB to
the new one.
This was a complicated process of its own, which I found nowhere
really explained, and it needed several iterations with a lot of
trial-and-error until I had this approximately correct.
Must I do something with the Indices after such a transfer?
Another point was a problem with UW-IMAP with default settings some
time ago.
Not here, our IMAP server is Cyrus.
Best regards,
Jochen Roderburg
--
IMP mailing list - Join the hunt: http://horde.org/bounties/#imp
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [email protected]
