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.
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.
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.
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 Domino Web Engine tab of the Internet site document for Web Protocol (if using Internet site documents).
in the server document (if not using Internet site documents), or by clicking theBefore 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.
- 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.