Tuning performance of the server

This topic describes memory, thread, logging and other considerations for the performance of the IBM Traveler server.

Memory

If you are running the IBM Traveler server on a 32-bit Microsoft™ Windows™ operating system, then you may need to take steps to reduce the memory usage by the core Domino® server. In this environment, dedicate the server to running IBM Traveler and do not run other Domino® applications on it. You should reduce the amount of memory that Domino® pre-allocates to the shared memory buffer pool by adding the following line to the Notes®.ini in your Domino® server program directory:

NSF_BUFFER_POOL_SIZE_MB=256

If this line is not present, then the Domino® server pre-allocates 512 MB of shared memory for buffers, which does not leave enough memory for other applications running on the server. To determine if your IBM Traveler server is running low on available memory, see the Mem Show section of the Resource usage topic.

On Windows™ 64 bit servers, increase the HTTP Maximum Cached users parameter to match the number of expected syncing devices. This value is present in the Domino® server document and can be changed using the Domino® Administrator client.

Also, for 64-bit servers, you may need to increase the maximum amount of memory allocated for the IBM Traveler Java™ heap. This parameter is called Maximum Memory Size and is found on the IBM Traveler tab of the Domino® server document. By default, this value is 1024 MB. Use either the Tell Traveler Mem or Tell Traveler Status commands to determine if your system is close to the maximum heap available. More Java™ memory allows the IBM Traveler task to run more efficiently, but make sure that your server has enough physical memory to allow expansion of this value. If you are encountering out of memory Java™ errors in the IBM Traveler task, then it is likely your Maximum Memory Size is set too low for the number of users that you are running.

Database defragging

The information in this section only applies to Derby/Single Server use cases.

As IBM Traveler installations become larger and run for extended periods of time, the internal database will grow in size. This can affect system performance. You can defrag the database to compact and optimize its performance.

For detailed information on this topic, refer to Defragmenting the internal database for improved performance.

HTTP threads

The Domino® HTTP server task must have enough threads to handle the number of HTTP requests from mobile devices accessing the IBM Traveler service. You can adjust the number of HTTP server threads using the IBM® Notes® Administrator client and modify the server document for the IBM Traveler server. In the server document, click Internet Protocol, then click HTTP and change the Number of active threads value.

To determine the optimal number of HTTP threads to allocate for IBM Traveler, take the number of devices and multiply by 1.2. For example, if you have 250 mobile devices, then your HTTP active threads value should be at least 300 (1.2 times 250). The HTTP server task allocates all of these threads at startup time and keeps them active as long as the server is started. Do not over-allocate HTTP threads as this causes the Domino® server to run out of memory.

Note: BlackBerry 10 devices tend to use more connections than other mobile devices. Therefore, the general rule of multiplying the number of devices by 1.2 may not be sufficient in calculating the number of HTTP threads and may need to be increased to 2 times the number of BlackBerry devices plus 1.2 times the number of non-BlackBerry devices. BlackBerry 10.3.1 and later releases include improvements to the number of connections utilized, which may reduce the number of HTTP threads. Please contact BlackBerry for additional information about connection utilization by specific BlackBerry 10 releases.

For more information on tuning HTTP threads, refer to Tuning active HTTP threads for IBM Traveler.

IBM Traveler threads

IBM Traveler is a multi-threaded Domino® task. IBM Traveler threads are dynamically tuned. In most case the administrator is unlikely to have to change these values. If these threads values are tuned it is important to balance the number of threads added and the additional memory required to handle the extra threads. Threads within the IBM Traveler server task are allocated only when needed, but when they are needed, there must be enough memory to allocate for the threads to start. Allocating too many threads can cause the system to crash due to out-of-memory errors.

The administrator can still manually tune the following thread pools:

Prime sync threads - Determines if changes to user mail files must be synced to user devices (specified in notes.ini as the value for NTS_THREADS_PRIMESYNC).
Device sync threads - Syncs data between Domino mail servers and user devices (the default is 5,000 threads and is specified in notes.ini as the value for NTS_THREADS_DEVICESYNC).
Worker device threads - Used internally to handle device requests including configuration, push and synchronization (specified in notes.ini as the value for NTS_THREADS_WORKER_DEVICE). Most actions associated with the syncing of data will be passed to a device sync thread.
Worker system threads - Used internally to handle all incoming requests including inter-server and inter-process communication (specified in notes.ini as the value for NTS_THREADS_WORKER_SYSTEM). Actions associated with a device will be passed to a worker device thread. Other actions will be processed on the worker system thread itself.

Note: Refer to Notes.ini settings for more information on the thread pool settings.

Logging

When debugging a specific problem, the IBM Traveler server should only be run at a logging level of FINEST. For problems that affect all users, the overall level should still be FINEST. But if the problem is specific to only a few users, then run only those users at the FINEST level, leaving the other users at the system level.

By default, all Traveler log files are contained in <Domino data dir>/IBM_TECHNICAL_SUPPORT/traveler/logs. If you want to move the log files to another location, modify the entry NTS_LOG_ROOT_DIR found in the notes.ini file. However, ensure that you place the files either under the IBM_TECHNICAL_SUPPORT directory or outside the Domino® directory tree completely. Do not place the files in the Domino® directory tree except under the IBM_TECHNICAL_SUPPORT directory tree. This is because, when starting or taking an NSD, Domino® views all files in the Domino® directory tree except for those under the IBM_TECHNICAL_SUPPORT directory. As a result, startup and NSD times can potentially be long if there are numerous files in the Domino® directory. The Traveler logs, especially if the FINEST level is being used, can include numerous files.

The following Tell commands are available through the Domino® console, and allow a user to exist at a different logging level than the system. For example, the system could be set at the FINER level while the user could be at FINEST until you resolve and remove the problem (which would set them back to the system level of FINER).


Command	Result
Log AddUser `level` `user`	Logs records for this user at the specified log level. This level overrides the system log level until this user is removed from the list.
Log RemoveUser `user`	Removes a user from the list of users that are logging at a level different from the system level. This use resumes logging at the system level. Remove all users by specifying *.

Customizing Address Cache User Allowances

If you want to customize the maximum numbers of users allowed into the Address Cache, you can do so my modifying the notes.ini file. Look for the NTS_ADDRESSCACHE_MAX_ENTRIES entry, which defaults to 10,000. Depending on the data traffic, you may want to increase the max entries number to avoid a high number of look ups. Systemdump includes this data, allowing you to determine if the cache is full, as well as which users are included.

Enabling session authentication

Performance can be enhanced by enabling single-server or multi-server session-based name-and-password authentication for web users. This allows the IBM Traveler client to log in once per session instead of logging in for each device-to-server communication. The session authentication parameter can be found by clicking Internet Protocols > Domino Web Engine in the server document (if not using Internet site documents), or by clicking the Domino Web Engine tab of the Internet site document for Web Protocol (if using Internet site documents).

Before enabling session authentication, make sure that you review the "Session Authentication" topic in the latest version of the Domino® Administrator documentation in this information center. Review the session authentication details, and make sure that it is the correct option for your environment.

Physical locations of servers

The utilization of high speed connections for servers is recommended. In addition, you should endeavor to physically place the Traveler servers as close to the mail servers as possible. Slow speeds across the connections can result in timeout errors.

Maintaining Derby database integrity

One of the most important responsibilities of a database administrator is to maintain the integrity of the database and prevent it from becoming corrupted.

Derby must be able to sync to disk. Some machine, disk, or operating system settings can prevent a proper sync and cause unrecoverable database corruption in the event of a power failure, system crash, or software crash. To avoid database corruption, you can do the following:

Do not enable disk write caching on the hard drive that holds the database. Disable write caching if it is turned on (it is enabled by default on many Windows systems). Disk write caching can increase operating system performance. However, it can also result in the loss of information if a power failure, equipment failure, or software failure occurs. Consult your operating system support documentation for information on how to disable disk write caching.
Run Derby on a local drive rather than on an NFS mounted, SMB mounted, or other network mounted disk. IBM Traveler puts the Derby information in the Domino data directory.
Disable any other settings or options that might prevent a proper sync to disk when Derby is writing its transaction logs or other data.