Q
Problem solve Get help with specific problems with your technologies, process and projects.

Indexing on a 'heavy' server

Hi. We have a Notes DB that has been around for many years and has slowly built up to contain over 200k in documents. The problem here is that although we have gone through an exercise of reducing the number of views each time, the index task runs everything on the server and slows it down. The server is a high-end one and we have just upgraded the network, too, with very little effect.

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.
200,000 documents is not so many for a server such as you describe.

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

This was last published in October 2003

Dig Deeper on Domino Resources - Part 5

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchWindowsServer

Search400

  • iSeries tutorials

    Search400.com's tutorials provide in-depth information on the iSeries. Our iSeries tutorials address areas you need to know about...

  • V6R1 upgrade planning checklist

    When upgrading to V6R1, make sure your software will be supported, your programs will function and the correct PTFs have been ...

  • Connecting multiple iSeries systems through DDM

    Working with databases over multiple iSeries systems can be simple when remotely connecting logical partitions with distributed ...

SearchDataCenter

SearchContentManagement

Close