Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Domino 8.5.3, Windows 2008 R2 running on ESX VM.

My question isn't about view performance, but more about the index process and how that effects other processes on the server. It appears if 1 view is being indexed, access to all views is "blocked" until that index process has started. All access is via the http task, so when user http request triggers view to be indexed, task manager shows HTTP as taking the CPU hit.

Some settings from our notes.ini:


UPDATE_NO_VIEWS=1 I am aware of this: ...I can provide more detail as to why we do this if required.


We takes steps to negate the above situation, but a simplification of our scenario that occurs every now and then is:

A DB with 300,000 docs in, and 4 views (A,B,C,D) and an api accessed via http that returns data from views A,B,C,D. HTTP thread pool (40 in our case) under full "expected" application load never saturates. All views are accessed constantly so view indexes are always up to date...accept in a specific case, which I can go into more detail if required.

Now lets say view D needs a re-index. Users are randomly accessing all 4 views, as soon as a user uses api call that retrieves data from view D, a re-index is started, all other users accessing data in views A,B,C are now blocked. The thread pool queue very quickly rises to 40 and all requests are pooled, so the app essentially stops working. Since 1,000s of requests are coming in a minute, raising thread pool will serve no purpose.

So it appears that if a view index starts on view D, access to all other views is blocked until it has finished. Is my understanding correct, and is there any way to alter this behavior? E.g. do not block access to other views.

Thanks in advance for any input or comments.

share|improve this question
I wasn't aware such a behaviour. Re-index is being trigerred programmatically? Also is there any Date or User-dependent column/selection formula in the database? – Serdar Basegmez Jul 14 '14 at 19:12
"Re-index is being triggered programmatically", not in the case I am describing (but we have sched agent to do this), simply a user accessing data in a specific view. When the app is at full load, there are many document creations\ edits, if a view has not been accessed in a while, the user calls some api call that retrieves a doc(s) from the view in question, vw.autoupdate = false set doc = vw.Getdocumentbykey(key), this causes a re-index of view. Access to all other views appears to then be blocked, every other api call that needs to access a view is blocked. HTTP thread pool full. – nick wall Jul 15 '14 at 8:07
Instead of an agent, did you try loading updall on a scheduled basis? – Serdar Basegmez Jul 15 '14 at 11:10
We used to to do that...there was some perf' issue...I think. It's been a while, will have to re-visit updall. Anyway, thanks for your comments. – nick wall Jul 17 '14 at 10:44
A follow up for myself more than anything else, load updall mydb.nsf -V, when runs, blocks\ dramatically slows HTTP thread requests to that DB. – nick wall Nov 13 '14 at 11:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.