How large databases uniquely affect IBM Lotus Domino server performance

[m3]

How large databases uniquely affect IBM Lotus Domino server performance

To recap our findings:

    * The size of a database can easily have a greater effect on performance than the number of users; however, that effect does not necessarily have to be the case. The greatest impact on performance is the size of the view or folder in use, specifically, the number of documents in a view or folder being used, assuming that transaction types and amounts remain the same.
    * The size or the total number of documents in the database did not prove to be an accurate predictor of the performance impact, under normal test loads. The data shows exponential growth rates for UPDATE_NOTE and NIF operation times as the number of documents in the inbox grew.

      Note, however, that a normal test load did not include database activities that could use significantly more resources, regardless of the size of a specific view. (For example, view rebuilds and maintenance operations can use a significant amount of additional resources to complete the same task.) Although total database size is not the greatest predictor of performance, it can still play a role.
    * The nature of the performance impact of concurrent users proved to be quite different from that of large databases. We saw that the nature of I/O appeared to indicate a sequential pattern, the inference being that differences in tuning might make it advantageous to group similar users together to take advantage of configuration differences.
    * The way in which physical memory is used can greatly affect performance. Configuration changes to the buffer pool, the use of multiple servers, and even the use of RAM disk showed that changes in how memory was configured could help overall performance. It could also hurt performance, although in general we found that the use of file-system cache in our tests tended to have less value, if there was an alternate method for using physical memory to relieve I/O operations.
    * The relationship between concurrency and the size of a database continues to be almost impossible to define accurately. To some degree, concurrency and size complement each other in their use of resources and overall effect on performance. For example, an administrator might decide that having a large database mixed in with smaller ones can hide the performance impact. On the other hand, because large databases might use the resources of a server more intensively and differently, it can be beneficial to isolate them from other databases.
    * Because a large database behaves differently and as such can react differently to tuning and configuration, it raises the question of whether large databases should exist separately so as to take advantage of those tunings or configurations. There does seem to be compelling evidence to indicate that might be value there. We hope that by more clearly defining the nature of large databases, we can improve our grasp on how to manage performance.