7.
Full text indexes
Consider whether to allow users to create full text indexes for their mail files, and avoid the use
of them whenever possible. These indexes are expensive to maintain since they take up CPU
processing time and disk space.
8.
Replication.
To improve replication performance, you may need to do the following:
y
Use selective replication
y
Replicate more often so there are fewer updates per replication
y
Schedule replications at off-peak hours
y
Set up replication groups based on replication priority. Set the replication priority to high,
medium, or low to replicate databases of different priorities at different times.
9. Unread
marks.
Select “Don’t maintain unread marks” in the advanced properties section of Database properties
if unread marks are not important. This can save a significant amount of cpu time on certain
applications.
Depending on the amount of changes being made to the database, not maintaining
unread marks can have a significant improvement. Test results in the lab with a Web shopping
applications have shown a cpu reduction of up to 20%. For mail, setting this in the NAB
decreased the cpu cost by 1-2%. Setting this in all of the user’s mail files showed a large
memory and cpu reduction (on the order of 5-10% for both). However, unread marks is an often
used feature for mail users, and should be disabled only after careful analysis of the tradeoff
between the performance gain and loss of usability.
10.
Don’t overwrite free space
Select “Don’t overwrite free space” in the advanced properties section of Database properties if
system security can be maintained through other means, such as the default of PUBLIC
*EXCLUDE for mail files. This can save on the order of 1-5% of cpu. Note you can set this for
the mail.box files as well.
11. Full vs. Half duplex on Ethernet LAN.
Ensure the iSeries and the Ethernet switches in the network are configured to enable a full duplex
connection in order to achieve maximum performance. Poor performance can result when
running half duplex. This seems rather obvious, but the connection may end up running half
duplex even if the i5/OS line description is set to full duplex and even if the switch is enabled for
full duplex processing. Both the line description duplex parameter and the switch must be set to
agree with each other, and typically it is best to use auto-negotiate to achieve this (*AUTO for the
duplex parameter in the line description). Just checking the settings is usually not sufficient, a
LAN tester must be plugged into the network to verify full vs. half duplex.
12. Transaction Logging.
Enabling transaction logging typically adds CPU cost and additional I/Os. These CPU and disk
costs can be justified if transaction logging is determined to be necessary for server reliability and
recovery speed. The redbook listed at the beginning of this chapter, “Domino for iSeries Sizing
and Performance Tuning,” contains an entire chapter on transaction logging and performance
impacts.
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008
Chapter 11 - Domino
166