TUNING


Database properties that optimize database performance

Properly setting database properties can improve the performance of an active database. Setting database performance properties on many databases or on one, large, active database can also improve server performance. In addition, some of these property settings also help reduce the size of databases. Many of these properties require knowledge of application design, and the database designer often sets these properties when creating a database.

For information on designing applications, see HCL Domino® Designer Help.

Display images after documents

To quickly display documents that contain images, select the Basics database property Display images after loading. Then Notes® users can read the text while the images load. If you don't load images after text, Notes loads images in the order in which they appear in a document; if an image appears first, Notes loads it before displaying text. With large images or slow connections, loading images in order may slow the display of the document.

This setting applies only when using Notes to view databases; Web browser settings control the display of images to Web browser users.

Note: Users also can specify Load images: On request in the Advanced section of a Location document to display images only when users click them. For more information, see HCL Notes Help.

Prevent the use of stored forms

To ensure that a document always displays correctly, you can store the form with the document. However, storing a form with every document uses system memory and may require as much as 20 times more disk space than not doing so. To save memory and disk space, you may want to prevent the use of stored forms, especially if users experience performance problems when trying to read the documents. To prevent the use of stored forms, deselect the Basics database property Allow use of stored forms in this database. Before preventing the use of stored forms, make sure you understand how this design feature works and how the database uses it.

Setting unread mark options

The Database dialog box contains a set of Unread Mark Options that you can use to maintain or not maintain unread marks, and to specify if unread marks with replicate to other servers. If you select the database property, Don't maintain unread marks, unread marks are not maintained for the database and the replicate unread marks settings are disabled. If you do not select the database property, Don't maintain unread marks, the replicate unread marks settings are enabled. You can do one of the following:

Note: Access these database properties by choosing File - Application - Properties and then clicking the details tab.


Don't maintain unread marks

Maintaining unread marks in a database requires system resources and can significantly slow database performance. For some databases, unread marks aren't useful -- for example, reference databases such as the Help databases provided with Domino, administration databases such as the Domino Directory, or databases such as the log file (LOG.NSF) that are continually updated. In these types of databases, consider disabling unread marks. To disable unread marks, select the Advanced database property Don't maintain unread marks.

Note: Designing views that don't display unread marks doesn't improve database performance because they are still maintained but not displayed.

If you select or deselect the Don't maintain unread marks property, you must compact the database so that the setting takes effect. Compacting in this case makes a temporary copy of the database, so your system must have the disk space to make the copy.

Tip: You can also run the Compact server task with the -u or -U option to enable or disable this property and then compact.

Replicate unread marks

Replicating unread marks requires system resources and can significantly slow database performance. Replication of unread marks was primarily designed for mail databases.

Associate document tables with forms for view updates

When updating a view, Domino refers to tables of document information. These tables are stored internally in the database. By default, during view updates and rebuilds, Domino searches each table for documents that appear in the view being updated. To update views more efficiently, select the Advanced database property Optimize document table map. This property associates tables with the forms used by the documents the tables contain. Then during a view update, Domino searches only the tables associated with the forms used by documents in the view being updated. This significantly improves the performance of view updates, especially updates of small views within large databases -- for example, the Connections view in the Domino Directory.

This property only works for views that use Form= as part of the selection criteria. There's a slight performance cost to maintaining the table/form association; however, when updating small views in large databases, the benefits offset the cost.

If you select or deselect the Document table bitmap optimization property, you must compact the database so that the setting takes effect. Compacting in this case makes a temporary copy of the database, so your system must have the disk space to make the copy.

Tip: You can also run the Compact server task with the -F or -f option to enable or disable this property and then compact.

Prevent overwriting of deleted data

When data is deleted from databases, Domino, by default, overwrites the deleted data on disk with a pattern. This pattern prevents an unauthorized user from using a utility to access the data. This overwriting affects disk I/O and can affect database performance.

Preventing the overwriting of deleted data is appropriate in these circumstances:


To prevent the overwriting of deleted data, select the Advanced database property Don't overwrite free space.

Don't maintain Accessed (In this file) document property

The Document Properties box displays the property Accessed (In this file) which can show the date a document was last modified or read. The Advanced database property Maintain LastAccessed property controls whether the Accessed (In this file) property is updated if the last document access was a read. Maintaining the Accessed (In this file) property for reads causes disk I/O that wouldn't otherwise occur.

By default, the database property Maintain LastAccessed propertyis not selected, meaning the Accessed (In this file) property is not updated when the last document access was a read, only when the last access was a document modification. Change the default behavior by selecting Maintain LastAccessed property.

You should select Maintain LastAccessed property if you use the document archiving tool, available in the Database Properties box, to delete documents based on days of inactivity.

Disable specialized response hierarchy information

By default every document stores information that associates it with a parent document or a response document. Only the @functions @AllChildren and @AllDescendants, which are often used in view selection and replication formulas, use this stored information. Maintaining this information has a significant, negative effect on database performance.

To improve database performance, disable the response hierarchy information in databases that don't use these @functions by selecting the Advanced database property Don't support specialized response hierarchy.

Disabling the response hierarchy information has no effect on views and replication formulas that display information hierarchically without using @AllChildren and @AllDescendants.

Disabling the response hierarchy information sets NotesDocument.Responses to 0 documents.

If you select or deselect the Don't support specialized response hierarchy property, you must compact the database so that the setting takes effect. Compacting in this case makes a temporary copy of the database, so your system must have the disk space to make the copy.

Tip: You can also run the Compact server task with the -h or -H option to enable or disable this property and then compact.

Prevent headline monitoring

Users can set up headline monitoring to automatically monitor databases for information that interests them. Monitoring a database this way affects performance, especially if many users do this. To prevent users from monitoring a database, select the Advanced database property Don't allow headline monitoring. You can also use the Security section of a Server document in the Domino Directory to control headline monitoring at the server level.

Allow more fields in a database

You can increase the number of fields in a database by selecting the advanced database property Allow more fields in database which allows the database to contain up to 23,000 fields.

For a database without this option selected, all the field names in a database when concatenated cannot exceed 64 kilobytes, which results in a database limit of approximately 3000 fields.

Use LZ1 compression for attachments

In Domino Designer, you can choose to compress attachments using the new LZ1 algorithm instead of the Huffman algorithm. Because LZ1 compression can be performed quickly and efficiently, it is favored over the Huffman method. However, if you are working in an environment that uses different versions of client and server software and you select this option, attachments are automatically recompressed on the server using the Huffman method. Note that recompressing has performance implications.

Note: The attachments in existing databases are not automatically compressed with the LZ1 algorithm when you choose the LZ1 algorithm. Files that are attached after the LZ1 algorithm option is enabled are compressed using the LZ1 algorithm. You can distinguish which compression algorithm is in use by checking the $File field in the document properties.

For more information on the LZ1 algorithm, see HCL Domino Designer Help.

Limit the size of $UpdatedBy fields

Every document includes an $UpdatedBy field that stores, by default, the name of the user or server associated with each document editing session. Storing a complete edit history consumes disk space and slows view updates and replication. To conserve disk space and improve database performance, use the Advanced database property Limit entries in $UpdatedBy fields to specify the number of entries that the $UpdatedBy field can contain. When the $UpdatedBy field reaches this limit, the oldest entry is removed to make room for the newest entry.

Limit the size of $Revisions fields

Every document includes a $Revisions field that stores, by default, the date and time of each document editing session. Domino uses this field to resolve replication or save conflicts that occur when two users simultaneously edit the same document on one replica or edit the same document on different replicas between replications.

By default, the $Revisions field stores a history of up to 500 edit sessions, each of which requires 8 bytes of disk space. Over time, $Revisions fields can grow large, taking up disk space and slowing view updates and replication. To conserve disk space and improve database performance, use the Advanced database property Limit entries in $Revisions fields to specify the number of entries that the $Revisions field can contain. When the $Revisions field reaches this limit, the oldest entry is removed to make room for the newest entry.

Consider limiting the entries in $Revisions fields on a database with all of the following characteristics:


A suggested maximum number is 10 entries in the $Revisions field. If you set the maximum as less than 10, you run the risk of increased replication or save conflicts.

Specify expiration time for soft deletions

When Allow soft deletions is selected, documents marked for deletion are held in the database for a specified time before they are deleted. On the Advanced tab of the Database Properties box, you can specify the number of hours documents are held before they are deleted from the database.

Use Domino Attachment and Object Service

When Use Domino Attachment and Object Service is selected, the database participates in attachment consolidation if the feature is enabled on the server. Newly created databases participate in consolidation by default. File attachments saved in documents in the database are added to a central attachment repository where they can be re-used by any databases that participate in consolidation. Each attachment is replaced in all documents that display it by a reference to the file's location in the repository.

On the DAOS tab in the Server document, you can enable attachment consolidation for the server, specify a minimum size for an attachment, and specify a file location on the server for the attachment repository. If an attachment is less than the minimum size, Domino refrains from consolidating it.

Attachment consolidation improves performance by significantly lowering the amount of disk space required to store attachments.

In this release of Domino, optimization of copying for DAOS objects prevents unnecessary copies of attachments from being transmitted between Notes clients and DAOS-enabled servers. This optimization results in significantly improved speed of transmission when replying to, forwarding, or replicating messages/documents that contain attachments already existing in the DAOS repository.

Compress database design

Database design compression refers to the compression of design elements in a Notes database. Compressing design elements, especially those including rich text and graphics, reduces their size on disk, and savings can be significant.

Compress document data

Document compression refers to the compression of non-summary (body) data in Notes documents. Compressing non-summary data reduces the size on disk of all rich text elements in documents, and savings can be significant, especially when a database contains lengthy documents including large graphic images.