Domino server performance optimization

(1) Understand your configuration

The Domino administrator should know the supported server configurations. The main components of any server include memory, CPU, and disk (including logical and physical). Other components, such as the number of online buffer memory and disk controllers, are also important.
The following are some additional considerations to avoid configuration problems:
1) Use a disk as fast as possible (for example, 10,000 RPMs ).
2) use hardware RAID on software RAID, which is faster and can reduce the CPU load.
3) A sufficient disk sub-system can reduce memory requirements because a small amount of temporary I/O is used for memory usage.
4) for the Windows NT platform, disk fragmentation can fully improve performance. We recommend that you clear disk fragments once a week.
5) Ensure that the server has at least 4 MB of memory available (10 to 20 mb better) even at the maximum load ). It should be noted that the Cache Policy of the platform may impede the operation.
6) standard server configurations are not necessarily optimal for Domino servers. The important thing is sufficient disks and controllers. You can use the NotesBench benchmark data of the hardware vendor as a guide.

(2) Allocating I/O through physical disks

Generally, physical and logical disk structures are system resources that people often ignore and are the most frequently overloaded. The best way to improve performance on many Domino servers is to allocate I/O through different physical disks.
Ideally, put the following I/O-related documents on different physical disks:
1) webpage documents on different platforms
2) Your NSF documentation
3) Domino R5 transaction log
If you can put them on different controllers, that's the best. This method improves I/O throughput by distributing loads on the bus, controller, port, and disk. Therefore, it is best to use a few small disks instead of a large disk. In particular, the more you isolate R5 transaction logs and other disk activities, the better your server performance.
Note: For some systems such AS/400, the operating system can automatically optimize data distribution between available disks and controllers.

(3) log performance data frequently

If you do not make a log of performance data, you cannot determine whether your adjustment is successful or failed. If you log frequently, you not only have a better understanding of what you do, but also provide detailed documentation for additional expenses.
You need to measure the data from the operating system and Domino. The following are major metrics (based on the platform ):
1) all CPU usage (expressed in percentages ). If the value is greater than 70% or 80%, a red flag is displayed on many platforms, such as Windows NT.
2) available memory or usage. Remember, when the available memory is less than 4 MB, the cache needs to be reduced.
3) disk sequence length (usually less than 2 items in the sequence) and average disk service time (for NT, it should be less than 70% ).
4) page document size and usage. Usage should be lower locally, or it is worth evaluating the usage and efficiency of your disk subsystem. For example, for the Domino Mail Server on the NT platform, the page usage should generally be less than 150 pages/second.
5) Domino statistics and events on mail throughput, replication, Web server activity, and database activity.
6) Domino logs (log. nsf) are cumbersome but useful (note that logs are enabled only when necessary because they affect server performance ).
Note that data is often collected and analyzed. It is necessary to capture performance data before or after major configuration changes.

(4) optimizing Domino R5

Domino R5 does a lot of work in automatic configuration and dynamic reconfiguration of key parameters to achieve maximum performance. The following are some suggestions on how to optimize the Domino R5 server itself:
1) correctly configure the number of mailboxes. Multiple mail. box documents can reduce competition for mail. box documents during email-related activities. When you add the second mail. box, the performance can be greatly improved. Experience is that we use a mail. box to support 1 ~ 200 users, two or more mail. box support 200 ~ 1000 users, up to 10 mail. Boxes support more than 10 users.
2) For non-partitioned systems, let Domino dynamically configure the NSF_Buffer_Pool_Size variable. This is especially important for low-memory server configurations. A large buffer will impede core memory management.
3) for the partition system, you need to allocate NSF_Buffer_Pool_Size, because Domino cannot automatically determine the actual available memory in each partition. The recommended formula is: (system memory/number of partitions)/4.
4) based on the available memory, let Domino allocate the mail transmission thread as needed (for local transmission ).
5) Assign the mail transmission thread to the Domino router as needed (to be sent to other servers ).
6) Use R5 transaction logs. It provides you with a large amount of complete data to enable the server to quickly start up and improve the performance by 10% ~ 20%.
Properly configure a Domino R5 server to run on a mid-range Windows NT machine. 20,000 messages can be transmitted per minute (each message has an average of 10 KB )!

(5) Use NotesBench benchmark data

Many benchmarks only tell your sellers what they want you to know, but the NotesBench benchmark is quite different. The NotesBench benchmark data allows you to make a thorough comparison of the Domino capacity on different hardware configurations of different vendors, and you can even use this data to estimate the total cost. Carefully reading NotesBench data and detailed reports provided by him is a good way to collect information. You can optimize your system configurations. Checks the disk structures, kernel configurations, patches, and so on used (or unused) by experts to obtain the maximum performance parameters from their systems.

(6) Signal Analysis

A signal is a communication mechanism used to process threads. Essentially, a signal uses a handshake mechanism to determine the use of resources. When the server is overloaded, the Administrator may receive a signal from the console. The following are some common signals from the observation of Domino 4.6 and explain what they mean in terms of performance:
1) Collection (0x30B) and Collection Queue (0x309). This implies that the CPU and memory have reached the bottleneck. The best solution is to extend the management process activity to idle time and optimize the I/O subsystem.
2) DB (0x245) and DB Queue (0x244): This implies that the database cache and disk I/O have reached the bottleneck. The best solution is to increase more memory and optimize the I/O system. Enabling domain-level replication is also helpful.
3) BTree (0x255): it implies how to store views and refresh view indexes. The best solution is to extend the refresh View index to idle time and optimize the I/O subsystem.

(7) Understanding the symptoms of server overload during use

A typical problem for the server is slow speed or mail transmission failure, which prolongs the user's response time and the time for searching for mail addresses.
To check the mail Transmission, you can view the percentage of your disk usage time and the length of the mail sequence. For R5, you can also check the number of mail. box documents and the number of local mail Transmission threads.
To improve the response time, We should optimize the distribution of I/O-related documents in the disk subsystem as much as possible.
If the address search is slow, users can use simple directories on their own clients, which reduces the load on servers and networks. You can also check the click rate of Name Lookup Cache. A good click rate should be 85%.
Check the number of HTTP threads and the percentage of disk usage time if the problem is slow page refreshing rate or the Web server that does not respond. Configure the number of HTTP threads to (one thread is used for every 10 users ).
How can I determine whether a server is fully used? For NT, the index is that the CPU usage is lower than 50%, the disk swap rate is lower than 50%, or there are often more than MB of available memory. However, note that the resource required by the newly added user may not be equal to the average resource of your current user. For example, as the number of users increases, each user's memory needs will be reduced because the fixed memory is allocated to more users.

(8) consider clustering

Clusters are the main feature of Domino Enterprise Servers. The cluster helps you achieve dynamic load balancing and automatically optimize resource usage in the cluster. In the group set, email and application failover can also be realized, including Web applications. You can combine R4 and R5 servers on any platform supported by Domino in a group, or cluster partition servers with unpartitioned servers.
The Domino cluster is the best way to increase the robustness and reliability of server resources. It is also the safest way to add R5 servers to the R4 cluster.
Based on your platform, a low-price system cluster can provide higher reliability than a single huge server at a lower initial cost. In addition, the cluster greatly reduces the number of users who fail to connect to the server. For example, on Windows NT platform, we recommend that you use a cluster if there are more than 750 active users in a system.

(9) Consider partitioning

Partitioning improves resource usage and the reliability of high-end Domino systems, and allows you to distribute servers by department or function while maintaining the benefits of consolidation. Some organizations even use partitions to create "service-level options" (that is, place some important managers in one partition and others in another partition ).
Generally, the number of partitions in the system should not exceed the number of CPUs. The AS/400 system is an exception and is suitable for partitioning. The AS/400 platform also logically isolates partitions, so even if one partition is broken, other partitions can still work normally.

(10) Know when to join and when to distribute

Unless you have a convincing reason, you can choose to join on the distribution as a growth strategy. Federation always reduces costs and improves reliability: fewer servers mean less complex server topology, less activity between servers, less network flow, less replication, and less email transmission between servers.
When should I select a distributed server instead of combining them? You may have a geographical distribution requirement. Local servers process local users and data at a low cost. Or you start to expand relatively small, but the growth is very fast, so add more servers to accommodate new users, or to make better use of the current investment.