Tuning performance of the server
This topic describes memory, thread, logging and other considerations for the performance of the HCL Traveler server.
Memory
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 HCL Traveler Java™ heap. By default, this value is calculated as 25% of the server's memory or 1024 MB, whichever value is greater. 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 HCL 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 HCL Traveler task, then it is likely your Maximum Memory Size is set too low for the number of users that you are running. This setting is tuned in the notes.ini file setting NTS_JAVA_PARMS.
If you are running the HCL 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 HCL 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 HCL Traveler server is running low on available memory, see the Mem Show section of the Resource usage topic.
Database defragging
The information in this section only applies to Derby/Single Server use cases.
As HCL 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 HCL Traveler service. You can adjust the number of HTTP server threads using the HCL Notes® Administrator client and modify the server document for the HCL 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 HCL 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.
For more information on tuning HTTP threads, refer to Tuning active HTTP threads for HCL Traveler.
HCL Traveler threads
HCL Traveler is a multi-threaded Domino® task. HCL 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 HCL 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.
Operating System threads
To support all the threads (HTTP and Traveler) needed, the operating system may have
to be tuned in order to prevent the system from running out of threads. On Linux
operating systems, the user process limit (ulimit) controls the number of threads
that can be started at any point in time. The default process limit (sometimes as
low as 1024) can be too low for normal Traveler server functionality. The Traveler
systemdump (see Diagnostic commands) provides a section titled
"Operating System Limits" that gives a snapshot of the limits for the server
operating system. In addition, the traveler server collects statistics on each
thread type and the maximum allocated
(Traveler.Threadpool.Count.Max.thread-type statistics such as
Traveler.ThreadPool.Count.Max.DS.Count). These statistics will
give you an idea of the high water mark for the total thread usage. The user process
limit (ulimit) should allow for at least 20% more processes than the total of the
maximum Traveler thread count plus the configured number of HTTP threads. In
addition, if the server is serving other applications, the process limit should
account for their process requirements as well.
Logging
When debugging a specific problem, the HCL 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.
| 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 HCL Traveler client to log in once per session instead of logging in for each device-to-server communication.
It is recommended to enable multi-server session based authentication, also known as single sign-on (SSO), when running Traveler HA. In this scenario a session key (LTPA token) would be shared among all Traveler pool members, and the user would only need login once (per device) regardless of Traveler HA server. This LTPA token will have a defined expiration before prompting the user for credentials again.
The session authentication parameter can be found by clicking 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, or multi-server single sign on, review the content in the Domino help center. Before making changes, decide which configuration is the correct option for your environment.
If selecting session based authentication, additional steps are required for compatibility with Traveler.
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.
- 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. HCL 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.
Transaction logging
Domino® transaction logging captures changes made to a Domino database and writes them to a transaction log. Starting with HCL Domino 12.0, transaction logging is on by default. Transaction logging can impact disk performance, especially when running the Traveler server in a single server configuration with a Derby database. It is recommended that if transaction logging is enabled, it should be configured with a dedicated drive, per the Domino best practices. For more information, see Preparing for transaction logging.