Indexing on a 'heavy' server

We have tried changing the server settings to have users create indexes on local machines and not on the server, but this caused problems with the NAB. We also tried creating multiple index tasks -- again to no effect. Soon we will be looking at streamlining the view selection formulas. Archiving is not an option. If there is anything else you can think of, I'd be very grateful. Here's the server spec: two servers in a cluster with 2 GB RAM, clustered dual PIII Xeon 1 Ghz, 90 GB hard drive Raid 5 and +1 GB virtual memory.

When you talk about the index tasks, I assume you mean UPDATE and UPDALL. If these are taking a long time to run, you might want to look at the following:

1. Reduce the complexity of your view selection formulas (as you already suggested) and also view columns formulas.

2. Get rid of views whose selection formulas or column formulas use @Now or @Today. Look into using single-category embedded views instead.

3. Avoid modifying documents needlessly. If you have any agents that regularly update every document in the database, get rid of them. Every modified document must be reinserted into the indexes.

4. Avoid deleting and re-creating documents.

5. Reduce the number of fields in your documents. If you don't absolutely have to store a field in the document -- if it can be calculated by a computed for display field instead of stored -- change it to CFD and write an agent to remove it from existing documents. If you have dozens of fields in a table, one per cell, replace the table with a Rich Text field and just let the user type what they like in the table, or use a table editing tool (find a few different ones in Domino Design Library Examples) to store one multi-value field for each column rather than one per cell.

6. Change the database properties to limit the number of $UpdatedBy and $Revisions entries stored. Ten is more than enough for most applications.

7. Read this redbook: Performance Considerations for Domino Applications