The Domino applications (single NSF) are supported up to 64-GB in size on the Windows and UNIX platforms. This section describes certain best practices for scaling the application for maximum accessibility and performance, including various application settings and deployment scenarios.
Fundamental scalability techniques
At the application level, you can use the following techniques to assure maximum application scalability:
Advanced scalability techniques
- Limit number and complexity of views.
- Avoid unnecessarily modifying documents, and avoid deleting documents and then creating documents exactly like the ones you just deleted.
- Database properties that can impact the overall size (see below).
- Database quotas
- Archive documents
- Selective replication
- Deletion stubs - limit how long they are kept (but bear in mind that this will affect replication)
- User activity logging (slows things down)
- Soft deletions
These techniques are typically used for applications that have large numbers of users who rely on the Domino web engine to access the application, and, for applications that may exceed the 64GB limit imposed above:
- Domino clustering
- Internet clustering
- Store the data in an external relational database management system using Domino Enterprise Connection Services (DECS) and Lotus Enterprise Integrator (LEI)
Compaction is a process used by the Domino Server (and Notes Client) to perform many maintenance functions on a Domino application. For the purposes of our discussion, we focus on the Domino Server commands for application compaction, and, discuss the best practices for getting the most out of application compaction.
The compact command is invoked by using the following command syntax:
- From the server console:
LOAD COMPACT ApplicationName.NSF –Options
- From a Notes client:
- Open a command prompt.
- Using the CD command, change to the Lotus Notes program directory. For example, CD "\Program Files\IBM\Lotus\Notes"as
- Run NCOMPACT ApplicationName.NSF –Options
For the complete list of Compact server command line options, see the TechNote # 1084388 at the Lotus Notes Support web site at http://www.lotus.com/support
Application properties for scalability
Each Domino application maintains an independent set of properties that control applications features, and application performance and scalability. You can access these properties from File -> Application -> Properties
menu, then select the Advance
), as shown:
Given the numerous possible application design scenarios, here we focus our discussion on general best practices for using the relevant properties which impact application scalability and performance. The following table shows a summary of the key application properties, from the Lotus Notes 8.5.3 C5 Beta Help. You must compact the application after enabling sand disabling one or more of these settings.
On-disk structure level
With each major release of Lotus Domino, IBM adds functional and performance enhancements to the database file. Each version of Domino ships with the same standard database file format, which is referred to as the on-disk structure (ODS). The on-disk structure level of a Domino application is an important consideration in any application deployment.
For example, the Domino Attachment and Object Service (DAOS) is a storage method whereas all file attachments are stored in a single repository and referenced as needed. This saves storage in the NSF and on your Domino server.
To use DAOS, you must have you mail databases set to, at a minimum, ODS 50. If an application is set to a lower ODS level, you cannot access the Domino application property that relates to DAOS, as shown:
To upgrade server-based applications to ODS 51, the latest ODS version for Domino 8.5.3, issue the following console command:
LOAD COMPACT –c <databasename.nsf>
To have Notes automatically create new databases using ODS 51, add the following parameter to the NOTES.INI file:
Best practices for on-disk structure management
- Domino applications should always be upgraded to the latest supported ODS level.
- The ODS level does not replicate, therefore, you must plan to upgrade all applications on all machines – client and server.
- For Servers, the ODS level should be set to the highest level supported by that version of Domino.
- For Clients, the ODS level should be set to the highest level supported by that version of the Notes Client.
- To have new Domino applications created using ODS Level 51, enter the Create_R85_Databases=1 parameter in the NOTES.INI file.
- To upgrade existing Domino applications to ODS 51, issue the console command LOAD COMPACT –c .
As a true rich information store, a Domino application can handle a variety of data (text, numbers, graphics, and attachments) quickly and easily. From a usability standpoint, attachments can degrade system and application performance, unless care is taken to properly handle applications containing many attachments.
If your applications require extensive use of file attachments (such as spreadsheets, documents, presentations, PDF files, and so on), you must carefully look at various settings that can impact the performance of both the application and the system as a whole.
These considerations include the number of attachments, the types of attachments, search options, and methods that you can deploy to help Domino more efficiently handle these operations on your application.
Attachment consideration: Number of attachments
As the number of attachments grows, our application must manage and maintain them. In the case of electronic mail, this problem becomes even more cumbersome.
If you e-mail a 20K document to 10 users, as a messaging system, Domino by default, stores ten copies of that document on the Domino server (one for each recipient). Therefore, the 20K document has ballooned to 200K of storage for Domino to manage. While this example may seem trivial, consider multiplying this over an average number of e-mails per day, and, the average number of recipients in an organization.
To help solve this issue, Domino 8.5 allows you to enable the Domino Attachment and Object Service (DAOS). This service, when configured properly, can eliminate the problem outlined in the previous scenario by allowing Domino to store only one copy of the attachment in a separate repository. The functionality is best shown by example:
Attachment consideration: Full-text indexing
As a complete search solution, the full-text indexing is not only index the documents but the attachment content as well, causing excessive use of storage to store the full-text index (located, by default, in the sale directory as the application, but stored in a separate folder named databaseName.ft folder). This fit
folder contains the full-text index that Domino uses to search for information, and can quickly balloon to more than the size of the actual application itself.
As developers, you must decide whether you want Domino to index the file attachments. This can be controlled using the Domino application properties box, as shown:
You can tell Domino whether you want to index attachments. The benefit of indexing the attachment is that search results will be more accurate because you
are searching the document and the physical attached file. The considerations include the size of the index and the increase in time that searching will take (because of the additional attachment information that has to be indexed), and, that index management time will increase due to Domino’s need to index the Notes document
the attached files.
do not want to index the attachment, but, still need to search the textual contents of the attachment, you
can contact the application vendor to see if they have an application programming interface (API) to access the contents of the attachment. You
could then write an agent (possibly in the QuerySave event of the form) that would extract the textual data from the attachment and store it in a hidden field within the document. Then, when you
search the document, you
are also searching the attachment text, but, without the excess performance hit of actually indexing the physical attachment. The trade-off being that the application increases in complexity, and that you are storing the textual information from the attachment twice – once in the physical attachment
and again in the Notes document.
While it would be optimal to have a Domino application comprise of a single storage facility, this may not be possible due to the complexity of the application, the number of documents, attachments, indexing, and design maintenance issues that can arise.
In instances where an application simply gets too big
for you (or Domino) to efficiently manage and maintain, you have the option to break the application into separate database files, working in tandem to form a complete, cohesive application experience.
The benefit of a multiple-database application is that information can be more efficiently processed by Domino. The consideration is that application integration from a Domino developer’s viewpoint can become more complex. As an example, consider a Sales Force application, defined as follows:
While this might appear to be a trivial application, consider the performance of the application with respect to:
- The number of views per data item (contacts, quotes, and so on)
- The number of attachments for customer documentation
- The overall number of documents housed in this application
From a performance and scalability perspective, it might be feasible to design the application using multiple data stores, as follows:
Some considerations when building multiple-database applications include:
- "Relational" database management:
In a multiple-database application, it is not uncommon for a document in one database to be related (or linked) to another document in another application. While Domino is not a Relational Database Management System (RDBMS) in the traditional sense, it is possible to link documents together using the Document identifier (DocumentID) uniquely assigned to each document or another unique value designed by the application developer.
- Application complexity and maintenance:
The application complexity and design maintenance will be more difficult because cross database references are required to be considered.
To effectively search for information, you have to implement a multi-database search (for example, implementing multi-database search in Lotus Domino)
Overall, and over time, the application performance will improve in the multi-database implementation. Your job as a developer will be more challenging, but, if you consider the performance and scalability advantages of a multi-database implementation of our applications, the benefits can far outweigh other factors.
Parent topic: 6.0 Performance considerations