Optimize Lotus Domino Server v6/8.x

Configuring server tasks

Each task increases the server’s load and can adversely affect its performance. Minimizing the number of server tasks that are run by the server, the frequency at which they run, and the time in which they run will enable you to increase the performance of the server. For example, these are the server task entries in notes.ini:

ServerTasksAt3=Object Info -Full

Each of these variables control the schedule for automatic server and database maintenance tasks. The first SeverTasks line denotes the services that are run when Domino starts while the other lines denote the scheduled server tasks. The time is entered in a 24-hour format, where 0 is 12:00 a.m. and 23 is 11:00 p.m. In the example above, Catalog and Design tasks would initiate at 1:00 a.m., and the Statlog task would initiate at 5:00 a.m.

You can significantly improve performance by removing tasks that are not appropriate to the server. Consider the following suggestions to increase performance related to Lotus Domino server tasks.

* These tasks should be turned off when they are not in use:

Scheduling: Turn off this task if you are not using the server for scheduling and calendaring.

AMgr: Turn off this task if you are not using the server to run scheduled agents. Remember, this function is not required for WebQuery Agents.

Collector, Reporter: Turn off this task if you are not using the server to automatically track server statistics on a regular basis. You can collect them on demand.
* Remove the Replicator (Replica) and Router tasks.

Both of these tasks can be removed if they are not being used on the server, because each of these tasks take up a fair amount of server resources when loaded. For example, if you have only one Lotus Domino server in your organization that is used for both applications and mail routing, you might not need the Replicator task, because you do not have any other servers from which to replicate (and because clients will be replicating from the Lotus Domino server, not vice versa).
* Carefully choose the times when server tasks are run.

Daily server tasks should not be run when other server tasks are running or at times when there are a lot of users using the Lotus Domino server. This allows the maximum amount of server resources to be available for each server task that is currently executing and for user sessions. Examples of such server tasks are Design, Catalog, Statlog, and customized Notes API programs that need to be run only once a day.

The entries in ServerTasks have the following uses:

ADMINP: The major Domino scheduler job running batch-like updates
AMGR: Domino Agent Manager; takes care of predefined agents
CALCONN: Connects the Domino calendar to other types of calendars
EVENT: Domino Event Handler
REPLICA: Domino database Replicator task
REPORT: Domino Report Generator (adding data to STATREP.NSF)
ROUTER: Domino Mail Routing task
SCHED: Domino Scheduler task
SERVER: The main Domino Server task
UPDATE: Updates the database indexes and views

Tip: A very obvious but important lesson about server tasks and functions is that if your organizational requirements have no need for a particular function, do not run it on your server!

Domino database indexing: controlling the Update task

The Update task is designed to run in the background and is intended to improve response time and performance by ensuring that when a user opens a database view, the user does not have to wait for it to be indexed.

Note: Do not remove the Update task from a server. If you do so, the Public Address Book will not be updated.

To improve view-indexing performance, you can run multiple Update tasks if your server has adequate CPU power. Doing this can affect server performance and is recommended primarily for multiprocessor machines. On a server with multiple processors, enable a maximum of one Update task per processor

This is done within the notes.ini file by adding the line:

Updaters = [number of processors]

Network performance (compression)

Network compression is an important performance feature offered in Lotus Notes/Domino 6. When you enable network compression, data is automatically compressed before it is sent over the network. This improves network performance, especially over slower line speeds.

Notes/Domino 6 network compression offers a number of immediate benefits. For example, by reducing the amount of data being transmitted, you can improve the performance of your routing and replicating hub servers, especially if they are currently laboring under heavy workloads. In addition, you can enable it by default, so all your users can take advantage of this functionality without having to select it themselves. Because network compression is a standard, out-of-the-box feature, it does not require any additional code, which helps simplify administration and requires fewer CPU resources to run.

Note the following statistics about the benefits of network compression:

* A 35-52% reduction in data transferred from the server to client
* A 26% reduction in data transferred from server to server

Modify the TCPIP line in the notes.ini file to enable network compression. The last parameter denotes compression:

TCPIP = TCP,0,15,0,,12320

Setting maximum mail threads for local delivery

The MailMaxDeliveryThreads setting determines the maximum number of threads the router can create to perform local mail delivery. The default number is 1. Increasing this value can improve message throughput for local deliveries. The ideal number usually falls in the range of 3 to 25, depending on the number of local deliveries on your Lotus Domino mail server.

MailMaxDeliveryThreads = [number]

Setting maximum mail transfer threads

The MailMaxThreads setting determines the maximum number of concurrent processes that the mail router can create to perform it’s mail transfers efficiently. The default setting is one thread per server port.

MailMaxThreads = [number]

Disabling per-user message caching by the IMAP task

This setting disables per-user message caching by the IMAP task. It can improve the capacity of a server by reducing memory consumption. However, response time for some user operations might be slower. If this setting is omitted, IMAP per-user message caching will be enabled.

To disable per-user message caching by the IMAP task, set the following value to 1:

NoMsgCache = [0 or 1]

Using Lotus Domino 6.5 database format

Databases that you create in Lotus Domino 6.5 perform considerably better than databases created in previous releases: Database operations require less I/O and fewer CPU resources, view rebuilding and updating is quicker, and memory and disk space allocation is improved.

Because of these performance improvements, limiting the size of the databases to improve database performance is less important than in past releases. The maximum database size for Lotus Domino 6.5 format databases is 64 GB.

Defining the number of databases cached simultaneously

If your server has sufficient memory, you can improve the performance of the server by increasing the number of databases that Lotus Domino can cache in memory at one time. To do so, use the NSF_DbCache_Maxentries statement in the NOTES.INI file. The default value is 25 or the NSF_Buffer_Pool_Size divided by 300 KB, whichever value is greater. The maximum number of databases that can be cached in memory is approximately 10,000. For short intervals, Lotus Domino will store up to 1.5 times the number entered for this variable.

Monitor the Database.DbCache.Hits statistic on your server. This indicates the number of times a database open request was satisfied by finding the database in cache. A high value indicates database cache is working effectively. If the ratio of Database.DbCache.Hits to InitialDbOpen is low, you might consider increasing NSF_DbCache_Maxentries.

To set the number of databases that a server can hold in its database cache at one time, set the NOTES.INI value as follows:

NSF_DbCache_Maxentries = [number]

In special circumstances, you might also want to disable the database caching. The database cache is enabled by default. To disable database caching, enter the following syntax on the Domino console:

Dbcache disable

The database cache keeps databases open. Use this command to disable the database cache when you need exclusive access to a file that might be in the database cache. For example, to run an application such as a virus checker or backup software, disable the cache. To re-enable the database cache, restart the server.

Optimizing database index update

In general, the fewer view indexes that the Indexer server task must update, the fewer server resources are used by this task. You can use the NOTES.INI variable Default_Index_Lifetime_Days to minimize the amount of effort required by the Indexer task when updating view indexes. The Default_Index_Lifetime_Days variable controls how long a view index is kept in a database before it is deleted due to non-use:

Default_Index_Lifetime_Days = [number of days]

Full-text indexes

Disable the updating of full-text indexes on a server if you do not have any full-text indexed databases on your server (and do not intend to have any). The NOTES.INI variable Update_No_Fulltext can be used to disable all full-text index updating on the server. You might want to use this variable to disable the updating of full-text indexes if, for example, you do not want users to create full-text indexes on their mail files on a mail server in order to save disk space on that server and to save the Indexer task the time and resources of updating these full-text indexes. This is a very good setting for mail and replication hub servers, which in most circumstances do not have any user connections. The full-text index variable is:

Update_No_Fulltext = [0 or 1]

Setting this value to 0 causes full-text indexes to be updated each time the Update task (a server command task) is executed, and setting the value to 1 disables all full-text indexing.

Maximum sessions

When a new user attempts to log on, if the current number of sessions is greater than the value of Server_MaxSessions (in the NOTES.INI file), the Lotus Domino server closes the least recently used session. In order for a session to be considered for closing, it must have been inactive for at least one minute. For example, if this parameter is set to 100, and the 101st person tries to access the Lotus Domino server, the Lotus Domino server drops the least-used session from the server in favor of this new session.

Note: Reducing the Server_MaxSessions value to a specific number will not prevent the server from allowing more than that number of concurrent active users on the server, but will drop the sessions soon after they become inactive. This frees up resources. Conversely, Domino will not close any session that has been idle for less than one minute regardless of the demand on the server.

Controlling minimum mail poll time

You can control the minimum allowable time in which Lotus Notes clients can poll for new mail. It is possible that your Lotus Domino server resources are being overtaxed by being constantly bombarded by requests for new mail from the Notes client machines if users have changed their default new mail notification check time from 15 minutes to a smaller number such as 2 or 5.

You can control the minimum frequency of these requests from the server by using the MinNewMailPoll NOTES.INI variable. This variable determines the minimum allowable checking time from clients regardless of the value specified on the client machines. No default is set during server setup. The syntax of this variable is as follows:

MinNewMailPoll = [minutes]

Setting up multiple replication tasks

You can improve server replication performance by running multiple replicator tasks simultaneously. By default, only one replicator task is executed. With a single replicator task running, if you want to replicate with multiple servers at the same time, the first replication must complete before the next one can start. Set the number of replicators by adding the following entry in the NOTES.INI file, where the value is the number of replicators:

Replicators = [number]

All other factors aside, it is recommend that you set the number of replicator tasks equal to the number of spoke servers with which the hub replicates. However, you should not exceed 20 replicators to avoid putting too much load on the server. If the server you intended to replicate is not a hub server, the recommended number of replicators should equal the number of processors on the server.

http://www.redbooks.ibm.com/abstracts/t … .html?Open


Leave a Reply