db.Search performance and cutoff date

We use a db.Search method in a database with 1000-2000 users, each of whom have reader/author access to a dozen or so of their own documents, but not to anyone else’s. Usage spikes on Monday morning and is fairly sleepy otherwise. (We use the Search instead of private views.)

The search builds a collection of their other documents to help prevent duplicates. All their other documents are most likely last modified in the last few weeks, but the database is many years old and there remains a chance that one or two documents are older than a few weeks.

My question is whether it would help performance to include the cutoff date parameter in the Search or to leave it at Nothing.

Thanks in advance,

Bill

Subject: RE: db.Search performance and cutoff date

It would help performance to specify a recent cutoff date so that it wouldn’t have to look at old documents. It doesn’t help to have a cutoff date so far in the past that it doesn’t exclude any documents from the search – it probably slows things down.

For peak performance, have a hidden view categorized by username, and GetAllEntriesByKey. This prevents the server having to examine each document to see whether the user has access to it.

Subject: View indexes, reader fields, and usage spikes (was db.Search performance and cutoff date)

The readers fields are a given, so the server will have to examine each doc to see if the user has access to it. We had semaphore errors on the server when we used views to look up the docs. The server still needs to re-index the view for each user. The spikes overtaxed the indexing process, bringing down the server. (I may have the details a little off, but the gist is the same.)

Regarding my original question, you brought up a good point: Is search performance better if you set a cutoff date far enough back so that almost no docs are excluded, or if you leave it set to Nothing?

Subject: RE: View indexes, reader fields, and usage spikes (was db.Search performance and cutoff date)

The server doesn’t need to re-index a view each time it’s used just because some – or even most – of the documents contain Readers fields. I think something else is going on there.

What’s up you can’t just use an embedded single-category view?