Theoretical device capacity

Each environment is different, influenced by the user base, hardware, network, geography and other factors. Virtualization can also have an impact on server capacity. HCL recommends monitoring the environment on a regular basis to understand if your environment is below, above or has reached capacity.

HCL has performed a theoretical capacity case study for HCL Domino 12 and Traveler 12. When planning your capacity, the sizing is based upon the number of devices, not the number of users. There is also a maximum number of devices allowed in a Traveler HA pool. In the case study, Linux was more performant. The performance for Windows remains the same as Domino and Traveler 11.

For HCL Traveler Server 12.0.1, a case study was performed running a mix of HTMO and mobile clients on a standalone Traveler server also running as the mail server. In this scenario, all mail files were local (which is required for HTMO clients). This configuration was able to sustain various combinations of mobile and HTMO clients up to a total of 500 clients. Prior to this study, other than proof of concepts, an enterprise database server was required for HTMO client support as well as requiring that mobile and HTMO clients be serviced by separate servers.

For high availability, plan to allow for at least one server to be down at a time. When supporting a failover event, the remaining servers must have enough capacity to serve the remaining users. The case study was performed with an n-1 model, meaning one server down in the pool at a time.

The findings of the case study are the following:

• A Traveler HA pool on Linux consisting of 5 servers was able to serve 21,000 devices with all devices active (requires HCL Domino 12.0.0 or higher).

• A Traveler HA pool on Windows consisting of 5 servers was able to serve 18,000 devices with all devices active.

Hardware

In the high capacity case study, the Linux servers had 8 CPU Cores and 16GB RAM. The Windows servers had 8 CPU Cores and 32GB RAM.

For additional detail on hardware recommendations, see the help topics on Memory and CPUs. In the case study, virtual servers were implemented in accordance with best practices.

Notes.ini tuning settings

The following settings are used to tune the Domino server in the case study:

Table 3. Notes.ini tuning settings used in the case study

Setting	Explanation
Create_R10_Databases=1	Enables ODS 53.
nsf_dbcache_maxentries=10000	Sets the maximum number of databases stored in the database cache.
NSF_BUFFER_POOL_SIZE_MB=4096	Sets the size of the NSF buffer pool, a section of memory used for buffering I/O transfers between the NSF and NIF subsystems and disk storage. This setting is highly dependent on the number of server partitions, users, size and number of views, number of databases, etc on the server. It is best to start with the default value (no setting) and allow Domino to automatically calculate this setting. See this topic for details.
NSF_MONITOR_POOL_SIZE_mb=200	Controls the size of the monitor buffer.
server_pool_tasks=100	Total number of physical threads in the Domino server (DbServer) threadpool. It is helpful to monitor the statistic “Server.ConcurrentTasks.Waiting” which should be zero. If there are tasks waiting this number should be raised.
server_max_concurrent_trans=1000	Sets the limit for the number of concurrently scheduled transactions on a server.

Server Document

These settings are provided to explain Domino HTTP tuning. Many factors can influence server tuning, these are the settings used in the case study. These settings are recommended in addition to the mandatory configuration settings as documented in the help center topic: Manually configuring the HTTP server. A full list of important settings are in the topics: Server Document settings. and HCL Traveler Server Document Settings.

Table 4. Server document settings

Location	Setting	Value	Explanation
Basics Tab	Load Internet Sites Configuration	Enabled	Enables Internet Sties
Internet Protocols - HTTP Tab - Basics	Number Active Threads	5300	Number of HTTP threads to process HTTP requests thereby limiting how many devices can be connected simultaneously. See the topic Tuning active HTTP threads for HCL Traveler for more details.
Internet Protocols – HTTP Tab - Timeouts	HTTP persistent connections	Enabled	Specifies if persistent connections are enabled
	Maximum requests per persistent connection	100	Maximum requests per persistent connection
	Persistent connection timeout	180	Persistent connection timeout (seconds)
	Request timeout	60	Number of seconds before HTTP request timeout.
	Input timeout	75	Input timeout (seconds)
	Output timeout	180	Output timeout (seconds)
Internet Protocols - HTTP - Protocol Limits	Maximum URL length	4	Length of the URL in KB
	Maximum number of URL path segments	64	Number of allowed segments in a URL
	Maximum number of request headers	48	Maximum number of lines in a HTTP header
	Maximum size of request headers (KB)	16	The maximum size in kilobytes of the request headers.
	Maximum size of request content	10000	This limit is normally only reached when trying to send mail from the device with large attachments which might put the request over this limit. See also "Maximum POST data (in kilobytes)"
Internet Protocols - Domino Web Engine - Memory Caches	Maximum cached users	1024	Set this to the number of expected concurrent users. It is the number of users cached by HTTP.
	Cached user expiration interval	3600	Generally, this should be 3600 or more to avoid expiring entries too quickly.
Internet Protocols - Domino Web Engine - POST Data	Maximum POST data (KB)	10000	This limit is normally only reached when trying to send mail from the device with large attachments which might put the request over this limit. See also "Maximum size of request content".
Internet Protocols - Domino Web Engine - Domino Access Services	Enabled Services	TravelerAdmin	Needs to include TravelerAdmin for the web admin to work properly.

Internet Sites Document

The use of internet sites document is not required, but is recommended. In addition to the below settings, the case study also had multiple server single sign on enabled.

Table 5. Internet Sites Document

Location	Setting	Value	Explanation
Web Site - Configuration - Allowed Methods	Methods	GET, POST, OPTIONS, PUT, DELETE	GET, HEAD, POST, OPTIONS, TRACE, PUT, DELETE, PATCH. GET and POST are always required. If Exchange ActiveSync is needed, then OPTIONS is also required. If the web admin is needed, PUT and DELETE are also required.
Web Site - Configuration - Domino Access Services	Enabled Services	TravelerAdmin	Needs to include TravelerAdmin for the web admin to work properly.

For more information on tuning your Traveler environment, see Tuning Performance of the Server. For information on monitoring Traveler server capacity, see Monitoring for capacity.