Capacity planning guidelines for IBM Traveler

There are a number of different factors you should consider when planning the type of computer system that will host the IBM Traveler application server.

They include:
  • Operating System selection and Domino® Server application type (32-bit vs. 64-bit)
  • Central Processing Unit speed and capacity
  • Disk storage configuration
  • Physical RAM availability
  • Back-end network speed

It is important to understand how each of these factors impacts a IBM Traveler server. You should not install a IBM Traveler server on an undersized machine. Initially, it may work fine for a small number of mobile devices, but it will likely experience degraded service later as additional devices are registered with the server. Note that this article provides general guidance only, and if you are looking for more specific information and hardware specifications, consider contacting your IBM® Sales Representative and asking them to connect you with a system sizing available through IBM® Techline.

The information presented first in this section was derived from testing with IBM Traveler in a stand alone configuration. Specific information relating to a IBM Traveler High Availability (HA) configuration is covered following the stand alone system guidance, and was derived from testing of an 8.5.3 Upgrade Pack 1 High Availability service pool configuration. Much of the information here is applicable to both environments. However, there are significant differences.

When planning a IBM Traveler high availability (HA) configuration, supported by 8.5.3 Upgrade Pack 1 and later, there are additional solution components that introduce new factors to consider beyond the IBM Traveler stand alone application server. These are:
  • A Service pool of multiple IBM Traveler servers
  • Enterprise Relational Database Server (accessed by all servers in the HA pool)
  • IP Sprayer (a single URL entry point and evenly spreads requests across the HA pool.)

For example, one major difference in an HA configuration, is that the disk I/O requirements are much less on the IBM Traveler servers because that processing is taking place on the enterprise database server. The disk I/O requirements for the database server are higher in order to support multiple IBM Traveler servers. For assistance with sizing a IBM Traveler HA environment, consider contacting your IBM® Sales Representative and asking them to connect you with a system sizing available through IBM® Techline.

Choosing an operating system and Domino® server type

IBM Traveler and the underlying Domino® subsystems require substantial amounts of system memory. The IBM® Traveler server must allocate resources to handle device requests as they connect to the server, but also must use resources even when devices are not actively syncing, so that push mail services are possible. The IBM Traveler server uses additional memory to cache certain data elements to reduce the number of queries made to the back-end Domino® mail servers. Furthermore, the Domino® HTTP engine requires that a thread is allocated at startup for each potential connection. These threads use a considerable amount of memory and it is recommended that you define the maximum number of HTTP active threads to be equal to 1.2 times the number of devices that are expected to access the server. Since IBM Traveler is push based, if these devices are turned on, they are likely using an HTTP thread to listen for push notifications.

Therefore, it is important to select an operating system and Domino® server application type that can support the maximum number of mobile devices that are expected to use the IBM Traveler server. Each of IBM Traveler's supported operating systems are listed with recommendations for each.

Microsoft™ Windows™ (32-bit) operating systems
Any application running on a Win32 platform is limited to 2 Gigabytes (GB) of virtual address space. IBM® Domino® and IBM Traveler support the native Win32 platform, but this combination is the least powerful of all supported OS and application combinations. 2GB of virtual address space must be shared by all applications that are using the Domino® platform. This platform is recommended only for smaller deployments of 300 devices or less. It is important to monitor memory usage to make sure that it is not approaching the 2GB limit.
Note: This operating system is supported in a IBM Traveler HA configuration only for the purposes of transferring data from the server to the HA pool data base. Once this data has been transferred to the HA pool database, the server should be removed from the configuration.
Linux™ (32-bit) operating systems
Similar to the discussion for Microsoft™ Windows™ (32-bit) operating systems. Linux™ 32-bit OS is only recommended for small deployments of 300 devices or less.
Note: This operating system is supported in a IBM Traveler HA configuration only for the purposes of transferring data from the server to the HA pool data base. Once this data has been transferred to the HA pool database, the server should be removed from the configuration.
Microsoft™ Windows™ (64-bit) operating systems

IBM® Domino® server and IBM Traveler both natively support Microsoft™ Windows™ running in 64-bit mode. This mode gives the applications access to the largest possible virtual memory address space. As a result, there is no worry about running out of application memory in this environment. This combination is capable of supporting the largest number of IBM Traveler devices and is generally only limited by other factors. Servers running in this environment are capable of supporting 2000 devices depending on the availability of other system resources.

For more specific information and hardware specifications for this Operating System option, consider contacting your IBM® Sales Representative and asking them to connect you with a system sizing available through IBM® Techline.

Linux™ (64-bit) operating systems

For more specific information and hardware specifications for this Operating System option, consider contacting your IBM® Sales Representative and asking them to connect you with a system sizing available through IBM® Techline.

IBM i operating systems
IBM Domino server and IBM Traveler both support 32-bit and 64-bit JVM on IBM i systems. However, IBM Domino server and IBM Traveler use 32-bit JVM by default on IBM i. If you exceed the requirements for Java heap memory or want to support the largest number of IBM Traveler devices, you can use 64-bit JVM by adding a notes.ini parameter. For more information, refer to Enabling IBM Traveler using a 64-bit JVM on IBM.

For more specific information and hardware specifications for this operating system option, consider contacting your IBM Sales Representative and asking them to connect you with a system sizing available through IBM Techline.

Processor capacity

IBM Traveler is a multi-threaded application which makes use of multiple processor cores available in modern servers. It is recommended that any IBM Traveler server be equipped with at least four processor cores. Larger installations with more than 1000 devices should be running at least eight cores. IBM Traveler makes extensive use of the processor as it converts data from Domino® formats to those that are acceptable on mobile devices.

Physical memory

It is recommended that a minimum of 8GB physical memory be installed with any system using a 64-bit operating system. If a 32-bit operating system is being used for a smaller device population, 4 GB of physical memory should be installed. For servers supporting more than 1000 devices, 16 GB is recommended. In these environments, the Maximum Java™ Memory allocated to the IBM Traveler server should be increased from 1GB to 4GB in systems where 16GB of physical memory has been deployed on the server. If you are running a 32-bit operating system, it is not recommended to increase the maximum amount of java memory beyond the default 512MB. Higher values could cause the system to run out of memory. If you require more memory, then you should move to a 64-bit operating environment.

For specific information on performance tuning memory for IBM Traveler, see Tuning performance of the server.

Disk configuration

For optimal performance for a stand alone server, the IBM Traveler server disk system should be configured to increase the performance of read and write operations to the physical disks. Using a RAID 0 disk configuration is suggested. IBM Traveler primarily uses the disk system to read and write sync state information for devices that are registered with the server. If you had a need to partition OS and Program Directory data onto different drives to save space, only the IBM® Domino® server data directory needs to physically reside on the RAID configured disk.

The IBM Traveler performance benchmark configuration was executed with 2000 users and devices, and required the following disk performance:
  • Windows™ 64/Domino 64 - 425 IOPs (I/O operations per second)
  • Linux™ 64/Domino 32 - 800 IOPs

These numbers were based on the workload used for benchmarking version 8.5.3. The IOPs in deployment may vary based on usage.

For information on estimating the disk space required for installing the IBM Traveler database, refer to this topic.

Back-end network speed

The bandwidth and speed of the network connection between the IBM Traveler server and the back-end Domino® mail servers impacts the response time of synchronization with mobile devices. It is recommended that back-end mail servers be co-located with the IBM Traveler server or be accessible through a high bandwidth connection. Often this means providing IBM Traveler servers in each geography around the world where you have also positioned clusters of mail servers. In general, ping response times of 50 m/s or greater between IBM Traveler and a mail server will result in significant throughput delays with sync. Having a large number of users on a slow mail server can impact the performance of other users on the server as threads spend most of their time waiting on high-latency requests with the mail servers.

Co-locating IBM Traveler with other applications

While it is possible to run the IBM Traveler server on the same physical server as other Domino® services (such as mail, iNotes®, Sametime® and BES), this is not recommended unless the deployment of users on the server is very small, typically less than 100 users. Once additional users are added, all of the applications will be vying for the same resources and the service will degrade. Performance benchmark tests that combine load tests of IBM Traveler with other application servers are not available, so only consider this route with a minimal numbers of users.

Using virtual machine services

Domino® and IBM Traveler do support running in a virtual instance. However, in general, virtual instances are known to reduce overall capacity of the system when compared to a physical installation. It is important to understand that IBM Traveler is a real-time critical application and any resources allocated to the IBM® Traveler instances should be allocated statically. If dynamic resources are used and other applications on the host are using resources when needed by IBM Traveler, then the service will degrade. Make sure that the virtual instance of the IBM Traveler server has static access to the recommended resources for a physical server (which means, it should have equivalent CPU, memory, and disk I/O).

In the case of a Traveler server being hosted on a VM, there are instances where performance problems or symptoms may arise, but the cause may be due to the VM environment/configuration. The information and screenshots provided below are available to help determine if the performance problem may exist due to virtual instance instead of at the Traveler level.

Please check the following areas to determine if the VM is the cause of a performance related issue:
  1. Click the Alarms tab to determine if there are any alerts available. If there are, engage your VMWare team as soon as possible to investigate.
  2. Check the CPU of the IBM Traveler server:
    1. Click the Performance tab.
    2. Click Advanced, then click the Chart Options link.
    3. For CPU, choose either Past week or the appropriate time frame for investigation.
    4. Under the Counters section, check the boxes for Usage and Ready.
    5. Click Apply or OK.
    6. Save the chart, either by taking a screenshot, or clicking the Save icon in the top right.
    The key when examining the chart is to look for critical thresholds and peak times, as well as patterns.
    • Usage: CPU Usage as a percentage during the interval (during the amount of time that was selected).
    • Ready: Percentage of time that the virtual machine was ready, but could not get scheduled to run on the physical CPU.

    A short spike in either Usage or Ready indicates that the system is making the best use of the host resources. However, if both values are constantly high, the hosts are probably overcommitted. Generally, if the CPU usage for a virtual machine is above 90%, and the CPU ready value is above 20%, performance is impacted.

    For more information, refer to this documentation topic.

  3. Check the memory of the IBM Traveler server:
    1. Under the Chart Options link, expand the Memory tree and select the amount of time to be analyzed. Longer periods help find trends.
    2. Under the Counters section, check the boxes for Usage and Consumed, and click OK.

      Usage information is given in a percentage format. The actual amount of memory used is also given.

    3. After analyzing the above information, check to see if there has been any ballooning or swapping.

      Under the Chart Options, change up the counters. Uncheck everything that was already selected, then check the boxes for Swap in rate and Balloon.

    4. Click Apply or OK.

    Notice that the graph is now displaying in KBps instead of percentages on the left side. On the right it is displaying KB.

    If a virtual machine has high ballooning or swapping, check the amount of free physical memory on the host (not the guest). A free memory value of 6% or less indicates that the host cannot meet the memory requirements. This leads to memory reclamation, which also may degrade performance. Engage your VMWare team if high ballooning or swapping is present. If so, most likely the host is running out of memory and taking it from the guest.

    For more information refer to this documentation topic.

  4. Check the disk of the IBM Traveler server:
    Note: In general, perfmon is the best choice for getting real disk statistics to show disk latency. However, it may be necessary to review a time when perfmon was not running. In this case, the disk statistics from the VM provider can be used.
    1. Click the Chart Options link.
    2. Expand the Disk tree and select the time frame for investigation. Typically, a week or month is sufficient.
    3. Under the Counters section, click the boxes for Usage and Highest Latency.
    4. Click Apply or OK.
    Note that the graph displays two types of data - KBps (the left side of the chart) and the other milliseconds (the right side). Usage is calculated in KBps and Latency is calculated in ms. Note also at the bottom of the chart where the legend is, that there is an average, minimum, and maximum designation. This will help you quickly understand if there has been at least one peak.
    • Usage: Aggregated disk I/O rate. For hosts, this metric includes the rates for all virtual machines running on the host during the collection interval.
    • Highest Latency: The highest latency value across all disks used by the host.

    Check for peak times of high usage and for latency. In general, latency should be 15ms or under. This indicates that the disk is keeping up with requests. If the latency goes over 25ms, it can impact application performance and end users will be affected.

    If you have enabled advanced logging (or esxtop), there may be additional options for disk i/o, which are superior.

    The following thresholds are from VMWare:
    • The kernelLatency data counter measures the average amount of time, in milliseconds, that the VMkernel spends processing each SCSI command. For best performance, the value should be 0-1 milliseconds. If the value is greater than 4ms, the virtual machines on the ESX/ESXi host are trying to send more throughput to the storage system than the configuration supports. Check the CPU usage and increase the queue depth.
    • The deviceLatency data counter measures the average amount of time, in milliseconds, to complete a SCSI command from the physical device. Depending on your hardware, a number greater than 15ms indicates there are most likely problems with the storage array. Move the active VMDK to a volume with more spindles or add disks to the LUN.
    • The queueLatency data counter measures the average amount of time taken per SCSI command in the VMkernel queue. This value must always be zero. If not, the workload is too high and the array cannot process the data fast enough.

    For more information, refer to this documentation topic.

  5. If physical resources are not dedicated to IBM Traveler, the server may become unresponsive or have poor performance. When resources are not allocated specifically to IBM Traveler on the VM, this becomes a limitation to the physical resources that the system has. To confirm if this is the case, access the NSD (or the systemdump on later versions of IBM Traveler) and find the following section: 
    Platform.LogicalDisk.x.AssignedName = *
Platform.LogicalDisk.2.AvgQueueLen = 2.26 
Platform.LogicalDisk.2.AvgQueueLen.Avg = 5.1484066438E+12
Platform.LogicalDisk.2.AvgQueueLen.Peak = 1.8446741005E+17

    Platform.LogicalDisk.x.AssignedName = * indicates the same disk as the data directory, for example, Directory=*:\Notes\data. Platform.LogicalDisk.2.AvgQueueLen.Avg should be below 0.2 on the system for the data directory that IBM Traveler is running on.

    For example, in the case above, 5.1484066438E+12 is an indication that the server is running into a limitation of physical resources. The issue can be solved by either allocating dedicated physical resources to the VM or by moving the IBM Traveler server to a physical machine.

Monitoring resource usage

It is important to evaluate your IBM Traveler server periodically to determine if you have provided adequate system resources for the number of devices that are using the server. In some cases, you may be able to tweak system configuration variables to improve performance or install additional physical resources to manage the load on a single server. In other cases, you may need to install additional IBM Traveler servers to handle the mobile device load.

Many system monitoring tools are built into the operating system on the IBM Traveler server. This article does not go into the details for how to use these tools, or other third party system management utilities that provide more comprehensive monitoring and reporting capabilities.

Note that the primary processes that will be consuming system resources in a IBM Traveler server are the Traveler and HTTP processes. On Windows™, this is ntraveler.exe and nhttp.exe. On Linux™, this is traveler and http processes running from the Domino® server directory.

The Domino® server provides platform statistic monitoring that must first be enabled on the system. See Platform statistics for information on how to enable Domino® server platform statistics.

Ideally, the average CPU usage on the IBM Traveler server across all running processes should be 75% or less. The command tell traveler mem will report both memory usage and CPU usage for the traveler process over the past 24 hours at 15 minute intervals. This report can be used to observe if your system is experiencing higher loads during different parts of the work day.

Use the command tell traveler mem to report memory utilization by the primary IBM Traveler process. 
 CPU and Memory (MB) Usage History  
 Date                       CPU Pct    Java Mem   C Mem      Avl Indx   # Users    # Errors  # DB Conn 
 2012-11-09 03:49:17 EST    0.20       48         2747       100        39         287       0         
 2012-11-09 04:04:17 EST    0.42       38         2747       100        39         287       0         
 2012-11-09 04:19:17 EST    0.23       42         2747       100        39         287       0         
 2012-11-09 04:34:17 EST    0.44       23         2747       100        39         287       0         
 2012-11-09 04:49:17 EST    0.37       73         2747       100        39         287       0         
 2012-11-09 05:04:17 EST    0.28       83         2747       100        39         287       0         
 2012-11-09 05:19:17 EST    0.21       67         2747       100        39         287       0         
 2012-11-09 05:34:17 EST    0.37       82         2747       100        39         287       0         
 2012-11-09 05:49:17 EST    0.22       23         2747       100        39         287       0         
 2012-11-09 06:04:18 EST    0.46       52         2747       100        39         287       0         
 2012-11-09 06:19:18 EST    0.27       40         2747       100        39         287       0         
 2012-11-09 06:34:18 EST    1.00       70         2757       100        39         287       0         
 2012-11-09 06:49:18 EST    0.31       95         2757       100        39         287       0         
 2012-11-09 07:04:18 EST    0.24       32         2755       100        39         287       1         
 2012-11-09 07:19:18 EST    1.11       50         2755       99         39         287       0         
 2012-11-09 07:34:19 EST    1.74       88         2757       99         39         290       0         
 2012-11-09 07:49:19 EST    0.76       75         2744       100        39         290       0         
 2012-11-09 08:04:19 EST    3.68       28         2744       97         39         290       0         
 2012-11-09 08:19:20 EST    2.87       85         2747       98         39         293       0         
 2012-11-09 08:34:20 EST    1.08       32         2744       99         39         293       0         
 2012-11-09 08:49:20 EST    1.21       53         2744       99         39         294       0         
 2012-11-09 09:04:20 EST    1.94       32         2745       99         39         294       1         
 2012-11-09 09:19:20 EST    1.37       76         2744       99         39         294       0         
 2012-11-09 09:34:20 EST    2.98       72         2744       98         39         294       0         
 2012-11-09 09:49:20 EST    1.30       79         2744       99         39         294       0         
 2012-11-09 10:04:22 EST    1.44       92         2745       99         39         294       0         
 2012-11-09 10:19:22 EST    1.43       29         2743       99         39         294       0         
 2012-11-09 10:34:22 EST    2.20       34         2742       98         39         294       0         
 2012-11-09 10:49:22 EST    3.96       59         2743       97         39         294       1         
 2012-11-09 11:04:22 EST    1.78       63         2743       99         39         294       0         
 2012-11-09 11:19:23 EST    3.53       37         2745       97         39         296       0         
 2012-11-09 11:34:23 EST    1.24       52         2743       99         39         296       1         
 2012-11-09 11:49:24 EST    1.49       83         2742       99         39         296       1         
 2012-11-09 12:04:24 EST    1.05       45         2742       99         39         296       0         
 2012-11-09 12:19:24 EST    1.62       66         2742       99         39         296       0         
 2012-11-09 12:34:25 EST    1.23       91         2746       99         39         296       1         
 2012-11-09 12:49:25 EST    3.50       39         2748       97         39         299       2         
 2012-11-09 13:04:25 EST    15.26      40         2750       85         39         300       1         
 2012-11-09 13:19:25 EST    1.62       25         2749       99         39         300       0         

 Current Memory Usage  
 Java Memory Usage 
  Max Total  1024 MB 
  Current Total  96 MB 
  Free   998 MB (97 percent of Max Total) 
  Allocated  26 MB (3 percent of Max Total) 
 C Memory Usage 
  Total Virtual  8388608 MB 
  Total Physical  6142 MB 
  Allocated  2748 MB (45 percent of Total Physical) 
 Current Usage 
  Java   26 MB 
  C   2748 MB
The IBM Traveler server will report data over the past 24 hours, as long as the server has been running for at least that long. The columns relevant to memory usage are:
  • Date - The time the collection was performed. This is done every 15 minutes.
  • CPU Pct - The percentage of the total CPU availability that is being used by the traveler process.
  • Java™ Mem - The number of Megabytes of memory that is being used by the Java™ Traveler server.
  • C Mem - The number of Megabytes of native operating system memory being used by IBM Traveler and all running Domino® processes.
The Current® Memory Usage section of the report gives a more detailed breakdown of the current memory usage.
Table 1. Java™ memory usage
Java™ Memory Usage

Max Available

This value is the maximum amount of memory that the Java™ heap is allowed to expand to. This value is defined on the IBM® Traveler tab of the Domino® server document. When running on a 32-bit system, this value should not exceed 1024 MB. A value higher than this does not leave enough memory available to other Domino® systems.

Current® Total

This is the amount of memory that the Java™ memory heap manager within the IBM Traveler process is currently managing. This value can grow as high as the Max Available value.

Available

The number of megabytes that are free within the current heap allocation. This value does not represent the total amount of memory that is available unless the Current® Total has expanded to the Max Available value. However, the value listed as (X percent of Max) does represent the accurate percentage of total available memory. This value should never drop to less than 15%. If it does, consider increasing the Max Available Java™ memory on the server document.

Allocated

The number of Megabytes of Java™ heap memory that is currently allocated and in use by the IBM Traveler server.
Table 2. C memory usage
C memory usage

Total

The amount of virtual memory that could be allocated in Megabytes.

Free

Virtual memory remaining in the system in Megabytes.

Allocated

Megabytes of native memory that have been allocated by IBM Traveler and all shared memory allocated by other Domino® processes running on the same server.

Important: On a 32-bit Domino® server, this value cannot exceed 2048MB.

When running in a stand alone configuration, the primary demand of IBM Traveler on the server disk subsystem is read and writes to its internal database which stores device sync state information. If the disk system cannot keep up with read and write requests, then the overall performance of the system can seriously degrade. Use the Domino® platform statistics to review the Platform.LogicalDisk.1.AvgQueueLen statistic for the logical disk that is hosting IBM Traveler's data directory. This value represents the number of read or write requests that have been queued at the OS level. A long queue means that the disk is not able to keep up with demand and is a bottleneck for the system. If the disk utilization (Platform.LogicalDisk.1.PctUtil) on Windows™ server is close to N*100%, where N spindles make the logical volume assigned to IBM Traveler, and the queue length (Platform.LogicalDisk.1.AvgQueueLen) is greater than the number of disk spindles on this partition, then there is a disk bottleneck. For Linux™ server, if the disk utilization (Platform.LogicalDisk.1.PctUtil) is close to 100% on the logical volume assigned to IBM Traveler, and the queue length (Platform.LogicalDisk.1.AvgQueueLen) is greater than the number of disk spindles on this partition, then there is a disk bottleneck. In this case, consider replacing the disk with a high performance RAID configuration and/or faster physical disk systems.

For example:
 Platform.LogicalDisk.1.AssignedName = C
 Platform.LogicalDisk.1.AvgQueueLen = 0.01
 Platform.LogicalDisk.1.AvgQueueLen.Avg = 0.02
 Platform.LogicalDisk.1.AvgQueueLen.Peak = 1.63
 Platform.LogicalDisk.1.PctUtil = 11.16
 Platform.LogicalDisk.1.PctUtil.Avg = 1.52
 Platform.LogicalDisk.1.PctUtil.Peak = 189.01

The Domino® HTTP server task must have enough threads to handle the number of HTTP requests from mobile devices accessing the IBM Traveler server. 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.

Domino® server statistics tracks the number of HTTP threads available and the number of active connections. At the Domino® console, issue the command:
show stat http.*

The statistic Http.Workers represents the maximum number of worker threads that are available to handle incoming HTTP requests. The statistic Http.CurrentConnections is the number of worker threads that are currently performing work, and the statistic Http.PeakConnections is the maximum number of connections used since server startup. Ensure that there are enough worker threads allocated to satisfy the Http.PeakConnections statistic.

If you are running IBM Traveler version 8.5.3 Upgrade Pack 1 or later, you can run the command tell traveler threads. Look for the HTTP Busy Thread counts line. This displays the current/peak/maximum number of HTTP threads, and is a convenient way to review this data.

Here is an example of the thread summary information:
 --- Summary (Tue Nov 03 09:24:31 EST 2015) ---
Shutdown requested: false
Threads total: 31
Threads available: 8
Threads busy: 23
Threads deadlocked: 0
Threads monitor deadlocked: 0

--- Busy Thread Counts (Name: Current / Peak / Max / Peak Time) (Tue Nov 03 09:24:31 EST 2015) ---   
DS: 1 / 16 / 5000 / Mon Nov 02 23:15:50 EST 2015   
PS: 0 / 3 / 200 / Mon Nov 02 12:52:51 EST 2015   
WS: 0 / 8 / 5000 / Tue Nov 03 08:01:13 EST 2015   
WD: 0 / 10 / 500 / Tue Nov 03 08:29:49 EST 2015   
TC: 2 / 2 / 50 / Mon Nov 02 14:24:16 EST 2015   
Alarm: 0 / 5 / 20 / Mon Nov 02 06:27:47 EST 2015   
VC: 0 / 4 / 20 / Mon Nov 02 05:42:08 EST 2015   
Mntr: 6 / 8 / 5000 / Tue Nov 03 01:53:46 EST 2015   
DelQ: 11 / 11 / 50 / Mon Nov 02 05:41:47 EST 2015   
Misc: 3 / 4 / 5000 / Mon Nov 02 05:41:47 EST 2015   
Push: 0 / 5 / 200 / Mon Nov 02 10:45:23 EST 2015   
HTTP: 14 / 23 / 400

For more information, see Tuning active HTTP threads for IBM Traveler.

Sample system deployments (stand alone)

The following configuration are recommended for dedicated IBM Traveler deployments. They should be used as a general guideline, and if more specific information is required then please contact IBM® Techline through your IBM® Sales Representative for a system sizing. Note that it is strongly recommended to choose 64-bit operating system for all deployment cases. Often the deployment population will expand rapidly beyond what was originally planned. Initially installing a 64-bit system can save a lot of rework time in the future.
Important: The following data is based on performance benchmark tests executed against version 8.5.3. This data will likely change as new releases are developed. For more specific information and hardware specifications that apply to your release of IBM Traveler, contact your IBM® Sales Representative and ask them to connect you with a system sizing available through IBM® Techline.
Table 3.
Maximum Devices Minimum Operating System Minimum Physical Memory Minimum CPU Cores
100 Win32 4GB 2
300 Win32/Linux32 4GB 4
1000 Win64/Linux64 8GB 4
2000 Linux™ 64-bit 16GB 8
2000 Windows™ 64-bit server 16GB 8

Additional guidelines for High Availability configurations

The IBM Traveler High Availability configuration provides for improved fault tolerance resulting in higher service availability, while also significantly increasing the effective capacity of the service accessible through a single address. The high availability configuration enables additional capacity to be added as needed for future growth without impacting the end user service availability. Some of the key system architecture differences include:
  • Deploys multiple IBM Traveler servers in a service pool.
  • The pool of IBM Traveler servers is accessed through a single URL.
  • All servers in a pool use an external shared enterprise relational database, containing the synchronization state data and administrative data. The internal database on each individual IBM Traveler server is no longer used. This enables any server in the HA pool to service requests from any user/device.
  • Can balance the load of requests among the pool of servers.
  • Can non-disruptively add servers to the pool when needed for capacity growth, as well as start and stop servers for maintenance.

The capacity planning for the high availability configuration is therefore done for each pool of IBM Traveler servers, together with its shared database management system resources comprising the HA solution configuration.

The IBM Traveler HA performance benchmark was executed with up to 12,000 user devices supported by a single service pool with the relational database systems also configured for high availability. These performance test results are used as the basis for the general capacity guidance in the following HA sections, and were based on the workload used for benchmarking the IBM Traveler 9 release. The resources required in deployment may vary based on usage.

Choosing an operating system and Domino® server type for High Availability configuration

The planning requirements specific to running in a high availability configuration are:
  • The IBM Traveler servers in a high availability configuration are required to run on 64-bit operating systems
  • The IBM Traveler servers in a high availability configuration are required to run on Domino® Enterprise 8.5.3.x

IBM Traveler Service Pool capacity

When planning a high availability service pool the two primary considerations are the total number of unique devices that must be supported by the pool and how much redundant capacity is desired. The redundancy is a decision on how many servers you wish to allow to be out of service at the same time (intentionally for planned reasons, or in case of unplanned system outages). To achieve the goal of high availability, plan for the pool capacity to adequately support the total number of unique devices required when at least one server is off line.

There is no design limit to how many IBM Traveler servers can be configured in a given pool. However there are practical performance limitations on the total real time transaction processing load to be handled on the relational database server. There are also practical performance limitations on how many unique devices are recommended to be supported per IBM Traveler server in the pool.

For an IBM Traveler server in the high availability pool configuration, the recommended maximum number of supported devices is 2,500 per server.

The recommended maximum number of unique devices that a IBM Traveler HA service pool can support is 10,000 based upon the performance stress testing results.

Note: If you need to support more than 10,000 unique mobile devices, then multiple service pools are required, each with its own separate database(s). Information is not shared across multiple pools.

To plan the minimum number of HA service pools required: Total Number of devices divided by 10,000 (rounded up to an integer).

To plan the minimum number of IBM Traveler servers in one service pool (up to the maximum of 10,000 unique devices):
  • Number of devices divided by 2500 (rounded up to an integer) plus 1 more for fail-over
  • Optionally, add any additional number of servers desired to achieve less load/server, or enable more than one to be off-line at a time.

Relational Database (DBMS) for High Availability

The use of a shared Relational Database Management System (DBMS) is new system component for deploying a IBM Traveler high availability configuration. Refer to the product Systems Requirements for the specific IBM® DB2® and Microsoft™ SQL Enterprise servers supported. Its capacity planning is critical to the overall operation and performance of the solution configuration, because one of the key capacity limiting resources can be the physical Input/Output required at the DBMS server. The capacity planning of the relational DBMS systems should be done in anticipation of the ultimate known target number of mobile user devices to be supported, if possible, so that over time it is easy to add IBM Traveler servers into a pool for capacity growth without having to make changes to the database server resources for that pool.

The DBMS system should not run on the same system as the IBM Traveler server application, and the DBMS should also be configured for high availability so that this critical shared resource is not a single point of failure. The IBM Traveler product HA configuration has been tested with Microsoft™ SQL Enterprise Server Mirroring and with IBM® DB2® HADR. Keep in mind when planning that this will require a redundant second DBMS server (per HA service pool).

DBMS Processor capacity and Physical Memory

For a pool supporting from 4,000 to 8,000 mobile devices, a DBMS system configured with a minimum of 4 CPU cores, and 16GB of physical memory is recommended. To support 8,000 to 10,000 devices, the recommended configuration should be increased to 8 CPU cores with 32GB of physical memory.

DBMS Disk configuration

For optimal performance of the high availability service pool, the DBMS server disk system should be configured to increase the performance of read and write operations to the physical disks. Much of the IBM Traveler server disk system read and write operations (performed when in stand alone) are now run instead at the Relational DBMS system on behalf of all the IBM Traveler Servers in the pool. The performance guidance is first, the Traveler Database disks drives should be separate from the disk drives for the Transaction Log; and second, the number of physical drives (spindles) needs to be able to deliver the required sustained Input/Output Operations per second (IOPS) for each.

Based upon the IBM Traveler HA performance benchmark, the following is a summary of the sustained IOPS required to deliver for different simulated user device loads:

Table 4. IBM® DB2® Database Server
Number of devices in Traveler Service pool Data Volume SUSTAINED Disk IOPs Transaction Log Volume SUSTAINED Disk IOPs
4,000 50 350
6,000 100 450
8,000 120 600
10,000 200 650
12,000 300 900
Table 5. Microsoft™ SQL Enterprise Server
Number of devices in Traveler Service pool Data Volume SUSTAINED Disk IOPs Transaction Log Volume SUSTAINED Disk IOPs
6,000 250 350
8,000 300 400
10,000 400 550

For information on estimating the disk space required for installing the IBM Traveler database, refer to this topic.

Load Balancing with Proxy/IP Sprayer

The capacity planning for the customer choice for an IP Sprayer in front of the IBM Traveler server pool is based upon anticipated traffic frequency from all mobile devices being served, and is typically measured in required connections per second.

The IP Sprayer should also be configured for fail-over, so that it is not a single point of failure.

Sample system deployments (High Availability pool)

The following configurations are recommended for IBM Traveler High Availability deployments. They should be used as a general guideline, and if more specific information is required, please contact IBM® Techline through your IBM® Sales Representative for a system sizing.
Note: 64-bit operating systems are required for High Availability deployment configurations, and must run on IBM® Domino® Enterprise 8.5.3.x (not Messaging).
Note: If deployed on virtual machines, each IBM Traveler server in the IBM Traveler server pool should be on a different VMware ESX server, to avoid single point of failure at the virtualization layer.
Important: The following data is based on performance benchmark tests executed against IBM Traveler 9. This data will likely change as new releases are developed. For more specific information and hardware specifications that apply to your release of IBM Traveler, contact your IBM® Sales Representative and ask them to connect you with a system sizing available through IBM® Techline.
Table 6. IBM Traveler servers in a HA pool
Maximum Devices per Server Minimum Operating System Minimum Physical Memory Minimum CPU Cores
3,000 Linux™ 64-bit 16GB 4
3,000 Windows™ 64-bit server 16GB 4
Table 7. Enterprise Database Server for the HA pool
Maximum Devices in Service pool Minimum Physical Memory Minimum CPU Cores Disk drives for Traveler Data Base Disk drives for Transaction Log
4,000 16GB 4 6 4
6,000 16GB 4 6 4
8,000 16GB 4 6 4
10,000 32GB 8 8 4
12,000 32GB 8 8 4
The following is an example of the Relational DBMS guidance for the maximum recommended IBM Traveler HA service pool capacity, for a database server supporting up to 12,000 devices in a Traveler Server pool:
  • 8 CPU cores, 32 GB RAM and 1,200 sustained IOPs
  • A dedicated (not shared with other applications) hardware RAID 5 (or better) LUN with 8 disks (8,000 to 12,000 devices) for the Traveler database
  • A dedicated (not shared with other applications) hardware RAID 1 (or better) with 4 disks for Transaction Log
  • The LUNs are dedicated, the storage system can be shared