Properties that improve 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. Database designers often set these properties when they create databases.

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.

Tip: 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 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.

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.

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 "Optimize document table map" 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:

The data is already secure -- for example, the database is on a server in a locked room.
Deleted space in the database is constantly reallocated -- for example, in a system database such as MAIL.BOX.
Data security isn't an issue -- for example, in an informal discussion database.

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 property" is not selected, meaning the "Accessed (In this file)" property isn't 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. All interfaces to the Responses property will return an empty collection.

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.

Disable transaction logging

Transaction logging captures all the changes made to a database and writes them to a transaction log. The logged transactions are then written to disk in a batch, either when resources are available or when scheduled. Disable the transaction log can improve database performance.

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."

Administrators 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 Release 6 and later, 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 (for example, a Domino® Designer 6 client and an R5 server) and you choose this option, attachments are automatically recompressed on the server using the Huffman method. Note that recompressing has performance implications. For best performance, use LZ1 in primarily Domino® 6 or later environments.

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:

The database contains many documents.
The database replicates often or has no replicas.
The database contains documents that are not often edited.

A suggested upper limit is 10 entries in the $Revisions field. If you set the limit 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.

Support Response Thread History

This option is new with release 8. If "Support Response Thread History" is selected, documents in the database contain additional information fields allowing them to be sorted into a document response hierarchy.

Note: Selecting this option has no effect on existing documents. Existing threads will not be identified or rendered as such and only new threads will take part in the feature. This is true even if a new replica or copy is made of a database with existing threads. Only new documents will be processed for thread citizenship and a place in the hierarchy.

Don't allow simple search

This option is new with release 8. When "Don't allow simple search" is selected, DbSearch is disabled. This allows the administrator to prevent searches against large databases, when it is not desirable to create new views or a full text index. If this option is selected, DbSearch code returns an error.