Performance

Many factors can affect the performance of Data Protection for IBM® Domino®. Performance can be improved by implementing some changes.

Many factors can affect the backup and restore performance of your Domino Server databases. Factors such as hardware configuration, network type, and capacity are beyond the control of Data Protection for HCL Domino. However, some parameters that are related to Data Protection for HCL Domino can be tuned for optimum performance.

Data Protection for HCL Domino uses multiple data buffers when it is transferring data between the Domino and IBM Storage Protect servers. The number and size of the buffers can be specified with the /buffers parameter. The number and size of buffers that are allocated by default can be configured through the set command or by selecting the Preferences item from the Edit menu on the Data Protection for HCL Domino GUI. The default number of buffers is 3 and the default buffer size is 1024 KB.

To reduce query processing time when querying the IBM Storage Protect server for databases to restore with the Data Protection for HCL Domino Windows GUI, specify a database name with letters and a wildcard character (*) in the By Database Name field. For example, specifying a* displays all databases that begin with the letter a regardless of the folder name. Specifying folder\a* selects all databases that begin with a in the specified folder and its sub folders. Make sure to click Update after you enter the query.

To improve throughput for backup and restore operations, run multiple sessions in parallel. This is most effective when work is partitioned by physical volume. For example, one Data Protection for HCL Domino session backs up all databases on one physical volume while a second Data Protection for HCL Domino session backs up all databases on another volume.

To improve throughput for backup operations, run multiple sessions in parallel.

On Windows systems, there are two ways to accomplish this.
  • When the databases are cleanly partitioned by a physical volume, you can start one Data Protection for HCL Domino instance to back up the databases on one physical volume. Then, start a second Data Protection for HCL Domino instance to back up the databases on another volume.
  • If the databases are not cleanly partitioned, you can start one Data Protection for HCL Domino instance to back up all databases and use the sessions parameter to create multiple independent threads and sessions with the IBM Storage Protect server. This is equivalent to starting multiple independent Data Protection for HCL Domino instances. The difference is that independent threads are used instead of independent instances. When you are using independent threads, you do not have explicit control of which databases are backed by the individual threads.

You can also specify tcpnodelay yes in the Data Protection for HCL Domino options file (dsm.opt) to improve backup and restore performance. Instead of buffering the data, this option sends the data as successive small packets across the network without delay.

The statistics option

The statistics option logs performance information about an individual database at the backup or restore level. Data Protection for HCL Domino processing is operated under two threads: a producer process (which reads the data) and a consumer process (which sends the data). During a backup, the producer reads the database and the consumer sends this data to the IBM Storage Protect server. During a restore, the producer receives the data from the IBM Storage Protect server and the consumer writes the restored database. The statistics option logs this information to help tuning Data Protection for HCL Domino optimal performance.

Example of the statistics option

In this example output, the consumer send rate is greater than the producer file read rate. Because the consumer completes sending the data before the producer completes filling the next buffer, it waits an average of 25 milliseconds for each read buffer that is filled by the producer. The best method for improving throughput would be to modify the input/output subsystem. If the send/receive rate was lower than the read/write rate, the best method for improving throughput would be to modify the TCP/IP subsystem. If both the producer and the consumer have significant average wait times and the send/receive and read/write rates are similar, then the best method for improving throughput would be to modify the processor. The standard Long Wait value is 0. A Long Wait value other than 0 is most likely caused by tape mounts being loaded during processing. As a result, the consumer send/receive time is artificially increased and not representative of the standard data transfer time.
=========================================================================
Request : SELECTIVE
Database Input List : Sample.db1.nsf
Number of Buffers : 2
Buffer Size : 1024
Logged Databases Only? : No
Wait for Tape Mounts? : No
Process Subdirectories? : No
TSM Options File : c:\Program Files\Tivoli\TSM\domino\dsm.opt
TSM Nodename Override :
-------------------------------------------------------------------------
Performance statistics for database Sample.db1.nsf
Section Total Time Wait Time Average Time Long Waits
(msec) (msec) (msec)
---------------------------------------------------------------------
Producer 231 1 0 0
Consumer 393 75 25 0
---------------------------------------------------------------------
Sub Section Total Time Bytes Transferred Transfer Rate
(msec) (bytes) (Kb/sec)
---------------------------------------------------------------------
ReadWrite 160 458752 2867
SendRecv 70 458752 6553
Domino Server 1 0 0
---------------------------------------------------------------------
Total Elapsed Time Total Bytes Transferred Rate
(msec) (bytes) (Kb/sec)
---------------------------------------------------------------------
1493 458752 307
Total Domino databases inspected: 1
Total Domino databases backed up: 1
Total Domino databases excluded: 0
Total Domino databases deduplicated: 0

Throughput rate: 300.07 Kb/Sec
Total byes inspected: 458,752
Total bytes transferred: 458,752
Total LanFree bytes transferred: 0
Total bytes before deduplication: 0
Total bytes after deduplication: 0
Data compressed by: 0.00%
Deduplication reduction: 0.00%
Total data reduction ratio: 0.00%
Elapsed processing time: 1.49 Secs
You can find more information about the statistics option in the description of Domdsmc set.

The sessions option

The sessions option allows a specified number of TCP/IP sessions to be made available for communication with the IBM Storage Protect server when you are backing up Domino NSF databases. Since more than one TCP/IP session is made available for backup processing, improvements in performance are possible. For example, the sessions option must be specified when simultaneously backing up NSF data to multiple tape drives. You can specify from 1 to 64 sessions. The default value is 1. However, be aware that since network and hardware capabilities of the production environment can also impact the overall performance enhancements of the sessions option, environment conditions must be considered when you are using the sessions option.

In addition, be aware that each session requests a mount point from the IBM Storage Protect server when backup processing begins. If a mount point is in use, then it is not released for use by a new session until the backup is complete. Because of this behavior, it is possible that a session (waiting for an available mount point) might timeout, causing the backup attempt to fail. This situation can occur when the number of specified backup sessions exceeds the number of available mount points. To avoid this situation, make sure that the number of available mount points (from the IBM Storage Protect server) is equal to the number of sessions that are specified with the sessions option. It is the responsibility of the user to determine the number of available mount points as Data Protection for HCL Domino does not determine this information. Also, the IBM Storage Protect Administrator must set the maxnummp option to specify the maximum number of mount points to use (for the Domino Server ID) on the IBM Storage Protect server.

The sessions option is available with the following commands:

The DOMTXNBYTELIMIT option

The DOMTXNBYTELIMIT=number option specifies the number of bytes sent between Data Protection for HCL Domino and the IBM Storage Protect server in a single transaction. The default value is 0, which indicates no limit, and the maximum value is 2097152. This number is multiplied by 1024 to calculate the limit in bytes.

This parameter is useful when you are backing up NSF databases to tape storage for these reasons:
  • Processing for each transaction causes the tape to stop and start. Considerable time can be lost during the stop and start when you are using high speed tapes. This is true in a LAN-free environment.
  • Errors that occur during backup processing are automatically tried again when domtxnbytelimit is set.

When a failure occurs during a backup, all of the backups in the transaction are tried again, not just the NSF database in error. Each backup is tried again in a separate transaction. After all backups are tried again, the domtxnbytelimit parameter is used to control the number of bytes per transaction.

The DOMTXNGROUPmax option

The DOMTXNGROUPmax=number option specifies the number of individual objects sent to the IBM Storage Protect server in a single transaction.

Two objects are sent to the IBM Storage Protect server for each database backup so the default value of this option is 2. The maximum value is 65000.

The DOMTXNGROUPmax option can be overridden by the IBM Storage Protect server TXNGRPMAX option. However, when domtxngroupmax is set, the minimum of the two values is used.

This parameter is useful when you are backing up NSF databases to tape storage for these reasons:
  • Processing for each transaction causes the tape to stop and start. Considerable time can be lost during the stop and start when you are using high speed tapes. This is true in a LAN-free environment.
  • Errors that occur during backup processing are automatically tried again when domtxngroupmax is set.

When a failure occurs during a backup, all of the backups in the transaction are tried again, not just the NSF database in error. Each backup is tried again in a separate transaction. After all backups are tried again, the domtxngroupmax parameter is used to control the number of individual objects per transaction. Consider running the domtxngroupmax parameter when you are backing up small NSF databases.