This document provides performance tuning information for IBM® Lotus® Quickr™ 8.5 for Domino® based on the experience of the IBM Collaboration Solutions Performance team.
The optimal tuning and the resulting system capacity can be affected by many factors, including the characteristics of the load on the system and the hardware used, including servers, disk subsystems, network topology, and more. Therefore, the settings in this document should not be considered the optimal values for every situation, but rather a starting point for tuning a Lotus Quickr for Domino deployment. When tuning your individual systems, it is important to begin with a baseline, and then monitor the performance metrics to determine if any parameters should be changed. When a change is made, monitor the same performance metrics to verify the effectiveness of the change.
Deployment topology and hardware considerations
Lotus Quickr 8.5 for Domino supports wide-ranging business requirements with a variety of deployment options. Choosing the most effective deployment topology requires evaluating security requirements, network infrastructure, and management complexity and integration with other products. This section describes types of deployment topology and strategies for obtaining high performance when building the Lotus Quickr 8.5 for Domino environment.
Information about installing Lotus Quickr 8.5 for Domino can be found in the Lotus Quickr Wiki at http://www-10.lotus.com/ldd/lqwiki.nsf/dx/Installing_and_upgrading_qd85
Domino single-server deployments
The single-server configuration of Lotus Quickr for Domino uses a Domino server and a separate LDAP directory server. In this most common topology, the Domino server serves HTTP requests directly.
Domino cluster deployments
A Domino cluster environment can provide high availability and increased capacity for the IBM Quickr for Domino services. More users can be supported by the clustering deployment. A Domino cluster provides greater reliability because one node failure does not cause the failure of the entire cluster.
There are two aspects to clustering: replication of data across the servers and load balancing of overall HTTP requests evenly distributed on the servers in the cluster.
There are two types of clustering: horizontal and vertical. Horizontal clustering refers to adding more systems to the cluster, while vertical clustering refers to adding additional server instances to the same system in the cluster.
The Domino cluster deployment topology consists of three tiers:
- The first tier is a load balancer, such as IBM WebSphere® Edge Server. The incoming client HTTP requests are routed by the edge server to a cluster of Lotus Quickr for Domino servers.
- The second tier consists of one or more Lotus Quickr for Domino servers, which are configured in a Domino cluster within same domain. The Domino cluster manager manages these nodes, and each node has its own storage in Domino databases. HTTP requests from the load balancer on the first tier is routed to one of the Quickr for Domino nodes. With session affinity, the load balancer attempts to route all requests associated with a particular session to the same node.
- The third tier includes the LDAP server used by the Lotus Quickr for Domino nodes.
Information about Domino clustering and deployment of Lotus Quickr 8.5 for Domino can be found in the Lotus Quickr Wiki at http://www-10.lotus.com/ldd/lqwiki.nsf/dx/Configuring_a_cluster_qd85
On a multi-core system, a vertical cluster of Lotus Quickr for Domino servers can be configured to provide high availability so that the server's processor capacity can be fully utilized. The vertical cluster deployment also consists of three tiers as described in the horizontal clustering. The only difference is in the second tier. Instead of adding more system, more Domino servers are installed on the same system as partition servers.
In the partitioned Domino server deployment for a TCP/IP network configuration, you can add more IP addresses or map the TCP port. We selected the configuration of assigning separate IP addresses for each partition server; therefore, less test environment change is needed. For more information, see the topic “Partitioned servers and IP addresses” in the Lotus Domino Information Center at http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=/com.ibm.help.domino.admin85.doc/H_PARTITIONED_SERVERS_OVER.html
: Horizontal and vertical clustering of Lotus Quickr 8.5 for Domino provides increased capacity and reliability compared to single server deployments.
Federated place catalog server deployment
When users open the MyPlace page, it causes a heavier transaction load on the Lotus Quickr for Domino server, because this MyPlace page is generated on the server using one single database of PlaceCatalog.nsf. To reduce this heavier load from the main Quickr server, we can deploy a separate PlaceCatalog server with the main Quickr server. This process is called federated place catalog server deployment. See the Lotus Quickr Wiki for more information at http://www-10.lotus.com/ldd/lqwiki.nsf/dx/Configuring_the_Place_Catalog_qd85
Disk I/O bottleneck
Lotus Quickr for Domino uses Domino databases to store the Quickr content. Each place created on the server generates at least three NSF files in the file system on the server. The main.nsf file contains the data of the place, the Contact1.nsf file keeps all members who can access this place, and the Search.nsf file saves the full text indexing information for searching the place. Thus, 2000 places populated on a server have a total of 6000 NSF files. When hundreds of users access the server, it causes a large number of file operations and disk I/O can become a bottleneck on a system with small number of disk drives.
If you suspect a disk bottleneck, track it in Microsoft® Windows® Performance Monitor (perfmon.exe) by selecting the Average Disk Queue Length counter for the disk driver with all database stored. If that counter is larger than two, or if you need to install a large number of Quickr places on the server, consider a disk array device with more spindle capacity, such as the IBM DS4700®/FAStT or a storage area network (SAN).
: Lotus Quickr 8.5 or Domino relies heavily on disk I/O, so attaching a faster storage device is deployment is preferred.
32-bit or 64-bit operating system considerations
Although IBM Quickr 8.5 for Domino is a 32-bit application, it is supported on both 32-bit and 64-bit operating systems. On 32-bit systems, process memory space is restricted by the 32-bit addressing limitations, and on 64-bit systems much larger process memory space is reserved. We found that Lotus Quickr 8.5 for Domino processes are not memory-constrained, so the operating system selection should not be a primary concern for planning a deployment.
Information about Lotus Quickr detailed system requirements can be found in the IBM Support Portal at http://www.ibm.com/support/docview.wss?rs=3264&uid=swg27009740
Tuning a Lotus Quickr for Domino environment involves configuring the various systems and components of the environment. This chapter discusses some general concepts and some specific details to help you tune your environment. These include:
- Configuring the Domino server and the resources defined for that application server, and tuning the Domino databases
- Tuning the operating system and network
- Tuning the directory server and its database, and following the LDAP server vendor's instruction.
When tuning your individual systems, it is important to begin with a baseline, monitor the performance metrics to determine if any parameters should be changed and, when a change is made, monitor the performance metrics to determine the effectiveness of the change.
Because Lotus Quickr for Domino is running as a Lotus Domino process on the Domino server, the parameters in the notes.ini file (normally found in the Lotus Domino directory on the Domino server) can be modified to improve the server performance.
Reduce the number of Domino processes
For a Lotus Quickr deployment, there are several Domino processes that are unused. Those process names can be removed from the server task list in the notes.ini file. For a Quickr deployment running on a nonclustered system, the only entry for the serverTasks
parameter should be the value HTTP:
For a Domino cluster, set the ServerTasks
values as follows:
=HTTP, AdminP, Replica,CLREPL,CLDBDIR
Even though only one (single-server) or three (cluster) tasks are listed in this parameter, the Domino server still starts other necessary processes such as: server, event, procmon, srvwrap and update. These processes are needed for a healthy Quickr server.
: In Domino notes.ini file, enable only the necessary tasks.
Quickr web cache considerations
The Lotus Quickr for Domino Web cache can save previous Web pages in its cache directory. When the next user requests the same page, the server can reload it from this cache directory. This caching operation saves many operations on the server side; however, the large amount of saved cache pages in the cache directory needs to be cleaned up periodically. This operation can cause the server to slow response. When users experience slow page responses during that period, disable the Web cache by setting:
Using the Domino NSF database cache
The following Domino NSF database cache settings in the notes.ini file are used to control the database cache:
= (number of Quickr places * 3)
= (number of Quickr places * 3)
is the maximum number of active or concurrent databases allowed to be cached on the Lotus Domino server. NSF_DBcache_Maxentries
is the maximum number of databases that a server can hold in its database cache at one time.
Increasing both cache sizes can improve the Domino server performance. These values that you set here depend on the place (3 * number) and room number on the Domino server.
: Set 3 * (number of places) to NSF_DBUCACHE_MAX_ENTRIES
in the Domino notes.ini.file.
Domino memory setting
The following Domino memory settings are available in the notes.ini file:
=4096 (default setting)
specifies the maximum size of the NSF buffer pool in MB. The default value is 512
. If you increase this value for better performance, the tradeoff is a larger memory footprint for HTTP processes. Check the maximum possible process bytes to determine the setting on a 32-bit operating systems. For 64-bit operating systems, the preferred value is 768
Domino server document settings
Changing some settings in the server document in the Domino server's names.nsf file can also improve Lotus Quickr performance.
In the server's names.nsf file, the server document contains pages for many configuration categories. Click the HTTP tab within the Internet Protocols tab to look at the following items:
- In the Basics section, increase the number of active threads setting from the default value of 40 to 120 for better performance.
- In the Timeouts section, disable HTTP persistent connections for better performance within the LAN, but keep it enabled for remote access.
- In the Network Settings sections, increase Listen Queue Size setting from the default value of 512 to 1024 to hold more incoming information. Increase the Maximum number of concurrent sessions setting from the default value of 2000 to 3000 to use more operating system resources for HTTP processes.
Click the Domino Web Engine tab within Internet protocols tab, to look at the following items:
- In the HTTP Sessions section, increase the Maximum active sessions from the default value of 1000 to 2000. Check the number of concurrent logged-in users to determine the Maximum active sessions setting.
- In Java Servlets section, increase the Maximum active sessions setting from the default value of 1000 to 2000. Check the number of concurrent logged-in users to determine the Maximum active sessions setting.
Configuration of the qpconfig.xml file settings
The Quickr for Domino server configuration file is qpconfig.xml and can be configured to improve server performance. Two changes are preferred here:
- Use an extra place view, which was introduced in Quickr 8.5 on Domino, to speed up the openMyPlace transaction. Locate the load_balance_places_view element. in the place_catalog entry in the qpconfig.xml file and set its attribute enabled=”true” :
<place_catalog enabled="true" log_level="0">
- Disable checking for whether Lotus Quickr Connector is installed on the users' systems. : Locate the roundTripEdit element in the connectors entry in the qpconfig.xml file and set its attachment enabled=”never” :
<roundTripEdit enabled="never" />
Place catalog database setting
Tuning the properties of the PlaceCatalog.nsf database can improve the server performance. Use the Lotus Notes administrator client to open the property window for the database of the PlaceCatalog.nsf databse. Click the tab on the right in the Advanced options section, and then make the following changes:
- Select Don't maintain unread marks
- Select Optimize document table map
- Select Don't overwrite free space
- Select Use LZ1 compression for attachments
- Set Limited entries in $UpdatedBy fields and Limited entries in $Revisions fields to a value of 5.
By default, both Limit entries in $UndateBy fields and Limit entries in $Revisions fields are unlimited. This setting causes the size of the PlaceCatalog.nsf database to increase over time. Set both parameters in the database to 5 to avoid this increase.
Network tuning on Windows operating systems
To fully use network bandwidth, you can tune several of the network parameters in Microsoft Windows operating systems.
The following registry changes can be applied on the Quickr server:
Be sure to backup your Windows Registry before making any changes.
TCPTimedWaitDelay and MaxUserPort
The TCPTimedWaitDelay parameter adjusts the amount of time that TCP waits before completely releasing a socket connection for reuse. The MaxUserPort parameter sets the number of actual ports that are available for connections, by setting the highest port value available for use by TCP.
To increase the throughput of the server, consider decreasing the TCPTimedWaitDelay setting from the default value of 120 seconds to 30 (0x1E) seconds. Increase the MaxUserPort parameter from the default value of 5000 to 65534 (0xFFFE).
The TCPWindowSize parameter sets the maximum size of a TCP window. With the large TCP window size, fewer acknowledgements are sent back and network communication between the sender and receiver is optimized. Consider changing the default value of 17520 bytes to 65535 (0xFFFF) bytes.
MaxHashTableSize and NumTcbTablePartitions
The MaxHashTableSize parameter controls the size of the TCP control block (TCB) table. The TCB table stores the control values for each active TCP connection. On a server with many active network connections, a large TCB table can reduce the amount of time spent by the system to locate a particular TCB. Consider changing the value of MaxHashTableSize from the default value of 512 (0x200) to 66536 (0x10000).
TCP performance also can be optimized by increasing the number of partitions in the TCB table. For multiple processor systems, this value is 4 multiplied by the number of processors. For example, on a quad-core processor system, change the NumTcbTablePartitions value to 16 (0x10).
Credits and feedback
Thanks to the following team members of the IBM Collaboration Solutions Performance Team for contributing to this document:
- Mohamed Bachiri, Manager
- Lihua Zheng
- Hai Jie Wu
- Steve Heyman
- Jiang Ma
If you have any questions or comments for the IBM Collaboration Solutions Performance team, log in to the wiki and add a comment at the end of this article.