Performance Basics for Lotus Notes Developers
It’s easy to develop simple applications in Lotus Notes and, if you have a few users and not too many documents, you’re unlikely to have performance issues. However, if your application is successful, you may accumulate lots of users and lots of data. If you haven’t designed it with performance in mind, your application will slow to a crawl.
This white paper discusses the main factors affecting Notes/Domino application performance and explains what you, as a developer, can do to maximize performance. This is not an exhaustive guide; rather, we focus on the design problems that are most common and most serious.
The following factors have the most impact on application performance generally:
• Number and complexity of views. Remove unused views or merge similar views. Where possible, use a re-sortable column to combine views that contain the same documents with different sorting. Remove unneeded columns, and simplify selection and view column formulas. Check for “server private†and other views to which you might not have access.
Use of @Today and @Now in view selection formulas or column formulas. Avoid if possible. Refer to the IBM Support Web site Techdoc, Time/Date views in Lotus Notes: What are the options?; also see the Views section of this article below.
• Number of documents. More documents make views slower to open. Consider archiving old documents or combining “main and response†documents into a single document. For instance, if your main document is an “orderâ€, it might be a bad idea to make a separate document for each “line item†on the order. Lotus Notes is not a relational database, but a document-oriented database.
• Number of summary fields stored in the documents. Every field that’s not rich text is called a “summary†field (though this is a slight oversimplification). Documents with more summary fields take more time to index into views (by up to about 30% if there are hundreds of fields). This is true even if the fields are not used in views. Sometimes using fewer documents requires more fields and vice versa; making the right choice for optimal performance requires thought.
• Complexity of forms. Attempt to limit forms to the number of fields you actually need. Long forms take substantially more time to open, refresh, and save (as well as contributing more fields that the view indexer must deal with).
• Modifying documents. Modifying documents unnecessarily slows view indexing by giving the indexer more work to do, and it also slows replication and full-text indexing.
• Number of deleted documents. When a document is deleted, it leaves behind a marker called a “deletion stub.†The replication program needs this to decide whether to delete the same document from another replica, or copy the “missing†document to this replica. Deletion stubs eventually age out (90-120 days is the default), so for a database with a normal number of deletions, you don’t accumulate enough to cause a problem.
However, we’ve seen applications in which there are many times more deletion stubs than documents. This usually occurs when there’s a nightly agent that deletes every document and then creates all new documents from some outside data source. Don’t do this. More advanced algorithms are available that compare documents with your source data and determine which ones need to be updated or deleted. See this Lotus Sandbox download for more information.
• Reader fields. If you need to use reader fields, then you need to – there’s no other way to get that level of security. But be aware of the performance impact in views, especially if the user has access to only a few documents out of many. The Views section of this paper includes some tips for minimizing the impact, as does the developerWorks article, Lotus Notes/Domino 7 application performance: Part 2: Optimizing database views.
• Number of users. A large number of users on a server drags down performance of the application (and of the server). And, if the application already had marginal performance, adding users makes it much worse. Correcting design issues can help, but you might also create replicas on other servers, especially clustered servers, or encourage users to create local replicas, which are much faster.
Viewed 8205 times by 2169 viewers
