These buttons link to parts of the text below
HCL Notes performance tuning is complicated, because there are so many potential performance issues. Possible problem areas include the hardware, the operating system and application design. If the application design is really poor, it will be difficult to fix it by tuning the storage subsystem. If the processors or memory are underpowered, then this will affect the Indexer speed, the Replicator speed, the number of maximum possible database transactions, and the number of add-ins that can run in parallel. If the Network is overused, then this will slow down all transactions.
From the storage viewpoint, disk access rates and configurations affect the general database performance and performance of views and view indexes. So if you are attacking a problem with Notes performance from the storage angle, you need to consider, and eliminate potential problems outside the storage sphere also.
So where do you start? With the Network! Run a simple TELNET data transfer between your Lotus Notes Server and a client, and see what kind of speed you get, compared to what you would expect from your network. If your network is rated at 10GB/s you will be lucky to ever see that, but you should see speeds of about 8Gb/s or more. If you are seeing less that 8b/s then you probably have network problems. You really need a network expert to check this out, as so many things could be wrong.
If the Telnet speeds are Ok, then you need to check that your Domino systems are using the network efficiently, On Windows, check the Processor Object, then the Percent DPC (Deferred Process Calls) Time and DPCs Queued/Second. These will give you an idea of how much processor time is spent servicing the network. If the DPC queue is growing, then you have an escalating problem.
If the network is Ok, look at the performance of your Domino servers. If you have one Domino server, which is accessing one disk drive, then really all you can do is suggest that your developers tune their application. This is outside the scope of a storage website but, here's a few ideas to throw at your developers. Constructive suggestions are always appreciated!
Domino is IO intensive, but modern disk subsystems using Flash drives, especially if they are fronted by SCM storage, should be able to cope. However, make sure that you have enough channel capacity to be able to cope. Make sure that the active workload is spread over all your available drives. Consider setting up disk drive partitions, and arranging the system, program, and data directories to distribute the workload across the drives as evenly as possible. You may have to experiment a bit to get this right.
If you are still using spinnng magnetic disks, then what you really need is disk subsystems which have large amounts of cache, so all writes go to cache, and most reads come from cache.
Server.Load is supplied with the Domino install CD. It is GUI based and provides some basic performance analysis data. Its simple to use, but just provides basic statistics.
There are several good third party products which report on Domino performance. An example is RoboMon from Heroix Corporation. This runs on Windows NT or Windows 2000 servers. As well as looking for bottlenecks in the IO subsystem, it will also give you some recommendations on how to fix developing problems. It checks on database sizes, compared to preset thresholds, and warns if databases are growing at unexpected rates.
NSF_UPDATEODS is a notes.ini setting that tells the client to update all databases to the latest ODS (On Disk Structure). This improves the client startup process and the process of opening local databases dramatically. Just add the following line to your notes.ini file. Where is your notes.ini? Well, it is usually located on your Notes programm directory. That is where your notes.exe resides. You should close Notes before you update your notes.ini!
This stuff is about changing the NOTES.INI file to get better debugging information about problems. Some of the commands are undocumented, so you should probably not be using them without talking to Lotus Support. However, if you know what the options are, then you know what to discuss with them. If you
decide to change NOTES.INI yourself, then please take a backup of your NOTES.INI file before you start.
Its not a good idea to change the NOTES.INI file using a text editor, the best way is to change it using the NOTES.INI Settings tab in the Server Configuration document of the Domino Directory. Some available options are -
to switch the trace to write to a file. That makes it much easier to analyze the trace afterwards. Its probably best to put this file into a separate partition, if you can, as its size is unpredictable. You don't want the trace log to fill up your main database partition. If the trace partition fills up, then Domino should stop tracing, but otherwise carry on processing as normal. The log file cannot be deleted while the Domino server is running; if an attempt is made to delete the file, a sharing violation will occur. If you specify a directory path for the trace file, then that path must exist. Domino will not create the path for you. Once the Debug-Outfile parameter has been added to the NOTES.INI file, the Domino server and the Server's Notes client must be shut down and restarted for logging to begin. it is important, however, to insert a carriage return after the last NOTES.INI entry.
and you will see a schedule dump every time the schedule is updated. This needs Domino R5 to work.
Debug-Repl-All=1The output looks like
03-02-2003 15:33:29 AM REPLICA: Updating NoteID 0x206F in Roles.nsf
03-02-2003 15:33:29 AM REPLICA: Deleting NoteID 0x205C in Roles.nsf
03-02-2003 05:31:00 AM REPLICA: ...Skipping note in Destination list
03-02-2003 05:31:00 AM REPLICA: ...(Con't)
Destination has same or newer note.
Src Time/SeqNo=03-02-2003 05:31:00 AM
You can store Domino databases on z/OS in two different file systems, VSAM HFS or zFS. If you use HFS, then you need to make sure that the files do not become full. Try to keep them at about 80% utilisation. DFSMS handles HFS file integrity on update, and can lock out access to the whole HFS file for one update. For that reason, its best to avoid large HFS files to minimise lockouts, and also avoid multi-volume files.
zFS has a better caching system. It detect sequential reads and pre-stage data in buffers to speed up performance. It also has a better lock/release mechanism. It is therefore much better to use zFS files for Domino databases.
The only major performance issue is channel utilisation, as Notes uses large block files. You need to monitor disk channel usage, and take action if it becomes excessive.