Set service.authcachesize equal to a number larger than the max concurrency of your user base. Setting this number higher than what your hardware can support could allow a Denial Of Service attack.
Set service.authcachettl equal to the number of seconds you want entries kept in cache. You need to weigh the problem of user password changes being seen against the performance hit of the mail system queries against LDAP.
Set local.ugldaphost equal to at least two dedicated LDAP consumers. If the first host should be unreachable or otherwise not working as expected then new connections will be created to the next working host in the list.
The length of time, in minutes, before LDAP connections are automatically closed and then re-established to the LDAP server. To adjust this timing, set the configutil parameter local.ldappoolrefreshinterval. The default value for this parameter is to never refresh. This also controls the length of time elapsed until the messaging server reverts back to the primary directory server.
The default timeout should an LDAP connection fail is 3 minutes, this can create a large overhead in failovers. There is an alternate method. Set local.ldapconnecttimeout to a value in seconds. This will enable a different connect function in the LDAP library. The timeout value should be chosen carefully. You need to consider things like temporary network issues and a very busy directory server. Setting the value to low will cause the mail server to close its current connections and start up new connections to the next server in its list. (Anyone have a suggested value? 30?)
Number of Processes
Set service.[POP|IMAP|HTTP].numprocesses, the default is 1. You want to set this high enough to support your user load but never higher than the total number of CPUs in the system.
I am looking for concrete information on this topic as in how to best guide people to tune their systems. At this point I do not have a lot of validated information. Something I do know is that you should not set maxthreads to be more than 250.
Turns out that I did not have all of the information regarding this parameter.
For deployments where the clients are mostly IMAP and most folders are not modified frequently, you do not want to set dbcachesize to the sum. Setting dbcachesize equal to the sum of *.db files can actually have negative impact on performance. This would result in the caching of data which is mostly stale. This would cause the process which syncs the in-memory database cache to disk to run longer due to the increased cache size.
The ideal setting of dbcachesize can be found in the following way:
1. Run 'db_stat -m' or 'db_stat -m -h /tmp/msg-<instance>'
(if store.dbtmpdir is set to /tmp/msg-<instance>).
2. The 3rd line tells you your current dbcachesize.
3. The 4th line shows the "hit rate", if it's close to 99%, your dbcachesize is correctly sized. Note: right after the messaging server starts up, the "hit rate" will be low; therefore you should let messaging server run for a period of time before assessing your "hit rate".
Sites have reported that the default of 16384K shows a "hit rate" of 99-100% even on our biggest installations (with over 200,000 folders).
Set store.dbtmpdir equal to /tmp/msg-<instance>. This parameter is related to Store DB Cache Size. Make sure the /tmp/ partition (or another tmpfs based file system) has enough free space to hold the database cache, that is the value of the store.dbcachesize.
Note -- the msg-&60;instance> is important, do not use just /tmp/, a subdirectory must be used. The file names placed in this location conflict with the MTA parameters of IMTA_TMP and IMTA_SCRATCH.
If you are using Netscape Directory Server 4.x series, then you should set local.ugldapbinddn equal to "cn=Directory Manager" as this will greatly improve the response time. If you are using Sun ONE Directory Server 5.x then you do not need to worry about this parameter. Though I have seen large sites (2 Million or more accounts) where this setting this to Directory Manager still provides a significant performance improvement. While I dislike setting it to Directory Manager for security reasons, sometimes the performance impact out weighs the risk.
This is the directory where webmail places out going messages from clients. If you have lots of webmail users you may want to consider setting this configutil variable, service.http.spooldir, to a fast file system.