ShowTable of Contents
IBM® Lotus® Quickr™ services for Domino® 8.2 uses Lotus Domino databases to store the Lotus Quickr content. Each place created on the server generates 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, for 512 places populated on the server, there are a total of 1,536 NSF files.
When hundreds of users access the server, it causes a large number of file read and write operations. As a result, disk I/O can become bottlenecked, most likely on a system with a small number of disk drives. When we originally set up our measurement environment, we used an IBM xSeries® server with the default three SCSI disks and a RAID-0 array was configured for the best performance. The initial performance measurement on this sever showed good disk activity. We used Microsoft Windows perfmon
tool to track the Average Disk Queue Length. When 500 users logged on and were interacting with the server, this value was over 9, meaning that there were an average of nine jobs in the queue waiting to perform I/O operations. This environment resulted in slow server response times. The disk I/O was the performance bottleneck.
Alleviating the bottleneck by deploying a FAStT device
To avoid the disk I/O bottleneck on the system, we moved to a disk array device. An IBM system storage DS4700®/FAStT device with fourteen 68 GB and 15KB RPM disks was attached to the Lotus Quickr server. With this configuration, the disk I/O bottleneck was significantly alleviated. For the mixed workload measurement at the reported capacity, the value of the Average Disk Queue Length was 2 on the Lotus Quickr Domino server, indicating that the storage device performed significantly better than the internal disk array.
Because Lotus Quickr is running as a Lotus Domino process on the server, the parameters in the Notes.ini file on the Lotus Domino server can be applied to improve its performance. Although some Notes.ini parameters are initially designed for the Lotus Domino server, applying them can make the Lotus Quickr perform better indirectly.
Reducing the Domino processes on the Lotus Quickr server
First, we focused on the Domino processes and unrelated process names were removed from the server task list in the Notes.ini file. For Lotus Quickr running on a nonclustered system, the serverTasks parameter value was HTTP:
Even though only one task was listed in this parameter, the Domino server still started other necessary processes, such as server, event, procmon, srvwrap and update. These processes were needed for a healthy Lotus Quickr server, so they were running throughout the measurement period.
Using the Lotus Quickr Web cache
The Lotus Quickr Web cache can save previous Web pages in one cache directory, so the next user requiring the same pages can reload them directly from the cache directory without opening the Domino NSF database. Because there were several Notes® API calls involved in creating a Web page on the Domino server, using the Web cache can eliminate these calls and improve the server performance. The cache directory should be on a separate drive other than the driver having all places database. For example, on a typical server, Lotus Quickr is installed on the C drive, the Domino Quickr database is installed on the D drive, and the Quickr cache directory can be put on the E drive. So the following parameters were added to server's Notes.ini file:
Using the Lotus Quickr user cache
The Lotus Quickr user cache can save the authentication information in cache for the previously logged in LDAP directory users. When the same user logs on multiple times, the caching operation removes the previously necessary round-trip time made to the LDAP server. The user authentication procedure speeds up and the overall performance improves. We applied the following parameters in the Notes.ini file:
Using the Domino NSF database cache
The following Domino NSF database cache settings were also applied in the Notes.ini file:
NSF_DBUCACHE_MAX_ENTRIES specifies 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 server performance. The value of these settings depend on the place and room number on the Domino server. Applying these parameters correctly in Notes.ini file improved the Lotus Quickr performance indirectly.
Changing Domino server document settings
Changing some settings of the Server Document in the server's names.nsf file can also improve Lotus Quickr performance. In the names.nsf file, open the server document, and on the HTTP Tab within Internet protocols tab, we changed the following items:
1. Increase the number of active threads from the default value of 40 to 120.
2. Disable HTTP persistent connection for the local environment to improve performance.
Limiting entries in the PlaceCatalog.nsf file
Limit the number of entries saved in the PlaceCatalog.nsf database to improve the server performance. By default, the unlimited number is assigned to the Limit entries in $UndateBy fields and Limit entries in $Revisions fields entries. This setting causes the size of the PlaceCatalog.nsf database to increase over time. We limit both parameters in the database to a value of 5 in our test.
Using the Notes administrator client to open the property window of the PlaceCatalog.nsf database, click the tab on the right and select "Don't maintain unread marks" in the Advanced options section. Add 5 into the bottom two fields as shown in the following screen capture:
Network tuning on Windows
In the benchmark measurement environment, a private network is used so that network capacity is not a performance bottleneck. However, to fully use the network bandwidth, we tuned several of the network parameters in the Windows operating system. This configuration was done on all of the Windows systems.
The following registry changes were applied on the Lotus Quickr server:
See the following discussion of each of these parameters.
TCPTimedWaitDelay and MaxUserPort parameters
TCPTimedWaitDelay adjusts the amount of time that TCP waits before completely releasing a socket connection for reuse. MaxUserPort sets the number of ports that are available for connections, by setting the highest port value available for use by TCP.
To increase the throughput of the server, we decreased TCPTimedWaitDelay from the default value of 120 seconds to 30 (0x1E) seconds and increased MaxUserPort from the default value of 5 KB to 65534 (0xFFFE) bytes.
TCPWindowSize sets the maximum TCP window. With the large TCP window size, fewer acknowledgements are sent back and more the network communication between the sender and receiver is optimized. We changed the default value of 17520 bytes to 65,535 (0xFFFF) bytes.
MaxHashTableSize and NumTcbTablePartitions parameters
MaxHashTableSize controls the size of the transmission 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. We changed 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, so the value was changed to 16 (0X10) to match our four-processor server.