Although this guide is indirected at the Domino Developer, knowing basic administrator skills is beneficiary in developing applications. After all, a developer can directly impact the performance of the server. This section describes certain settings that, although controlled by the administrator, might need adjustment depending on the intended use of the server from a development standpoint.
Java heap size
In Domino 8.5, a notes.ini parameter was automatically added to the Domino server:
This parameter was added to control memory allocation to allow the new XPages functionality to work correctly. Previously, the maximum
heap size was 64 MB. Starting in Domino 8.5.2, the default
value for the Java heap size was set to 64 MB, with a maximum of 256 MB.
The Domino Administrator should work with the Domino Developer to determine a suitable Java heap size. The appropriate setting most likely depends on your use of XPages:
- If you are not using XPages applications at this time, 256 MB is too much memory to allocate to the Java heap. The HTTPJVMMaxHeapSize value should be set to 64M (64 MB).
- If you are exclusively using XPages applications, you may want this value set to 256 MB to support the additional demands on memory that XPages require. To prevent Domino from resetting the value back to 64 MB (prior to Domino 8.5.2), an additional notes.ini parameter is required:
As described in 4.10 Scoped variables
, heavy use of scoped variables in an XPage application can affect the memory usage (and, thus, performance) of your Domino server. If using sessionScope and applicationScope variables, the default time out period is around 30 minutes. You can increase or decrease these amounts through application settings:
Increases to these values mean that the variables will remain in memory for longer periods of time, which could have a negative impact on performance.
The down side of a short timeout is that the user may be annoyed because they were in the middle of something, went to lunch or whatever, and the server logged them out. Gauge the appropriate value for this parameter based on your understanding of how people will use the application, expected server load, and total number of users of the application expected in a given period of time. For instance, a website for use by the general public, with thousands of subscribers, may need a short timeout compared to, say, a call center application where the same 100 people are using the application all day long.
Do not allow simple search
Code that does full text searches to build collections should be run against applications that have a full text index built and maintained by the Domino server. There is an application setting called “Don't allow simple search” that prevents a full text search from being performed against an application that does not have a full text index. This means that if you have a scheduled agent that does a full text search, and this property is enabled, your scheduled agent will fail. Without the property, the agent would build a temporary full text index in memory, search that index, and continue processing. This is very inefficient and can be very resource intensive on the Domino server. You should make sure that any time a full text search is going to be used in an application, there is a full text index created for that application.
The setting also affects users who may do searches in your application. In the Notes client, any user can open a search bar in a view and try to do a full-text search. If there is no full-text index, these user-initiated searches can be very resource intensive, so enabling this option prevents user actions from tying up the server.
Design and document compression
In order to reduce the disk spaced used by your application, you should enable the application property “compress database design”. This feature requires that the on disk structure (ODS) of the application be ODS 48 or later. Once the setting is enabled, you should work with your administrator to schedule a copy-style compact of the application to compress the design of existing design elements.
Furthermore, if your application contains large rich text fields, then enabling document compression is also a best practice. If your application has little or no rich text data, then it is best to not enable document compression. Again, the application must be at ODS 48 or higher, and a copy-style compact is required to compress existing document data.
Attaching large files with a browser
If you are designing a web application where potentially large file attachments are to be added to documents through a browser, you should work with your administrator. Attaching large files using web browser can create out of memory conditions on the Domino server. There is a notes.ini entry called DominoMultiPartPostBufferSize that can be used to control the size of the memory buffer used to process multi-part form data. You should work with your administrator to determine the appropriate value for this notes.ini entry.
User creation of views
As shown above, two ACL options can grant users access to create personal views on the server, or to create shared views on the server.
If you give ordinary end users these accesses, they may cause performance issues on your server by creating many views that will cause server slowdowns because of all the resources allocated to keeping the view indexes up to date. In addition, there's a potential security exposure that you should be conscious of.
If there's a legitimate need for a view, it's generally better for the end user to work with a developer to make sure the view fits into the UI scheme of the application, doesn't duplicate existing functionality, and is designed to minimally accomplish the needed task (e.g. that it has just the columns needed, not a column for every field on the form). Only trusted users who know what they're doing should be granted access to create shared views. Otherwise, you may see a proliferation of overly complex views that make a lot of work for the UPDATE task and cause slowdown of the server generally.
The performance penalty for "server private" views (the first of the two checkboxes) is less of a concern than for shared views. The indexes of server private views are not maintained by the UPDATE task; they are only refreshed when the user actually uses them. However, depending on the complexity of the view design, the number of documents in the view, and the amount of turnover, that can still be a fair amount of work for the server to execute on demand.
In terms of security exposure, we don't want to explain in detail, to avoid giving people instructions how to exploit this. Instead we will just state the principal: in applications that use Readers fields for document-level security, do not allow end users either of these accesses.
NOTE: Any user with a Notes client and Reader access to a database can also create "desktop private" views stored on their workstation. This may also make extra work for the server when the views are used, since the client will request summary information about all recently modified documents. However, it's not as much work for the server, and there's no setting to affect this anyway, so don't worry about it.
Parent topic: 6.0 Performance considerations