PERFORMANCE
Display images after documents
To quickly display documents that contain images, select the Basics database property "Display images after loading." Then IBM® Lotus® 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 the IBM Lotus 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
Note Access these database properties by choosing File - Application - Properties and then clicking the details tab. (The icon on this tab is a beanie.)
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:
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 IBM® Lotus® 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.
For information about enabling replication of unread marks, see the topic Replicating unread marks.
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 "Document table bitmap optimization." 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, IBM® Lotus® 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:
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.
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 IBM® Lotus® 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 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 environments that primarily Domino 6 or more recent.
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 the IBM® Lotus® 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. IBM® Lotus® 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:
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.