1

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:

UPDATERS=2

UPDATE_NO_VIEWS=1 I am aware of this: http://www-10.lotus.com/ldd/dominowiki.nsf/dx/http-and-view-index-performance ...I can provide more detail as to why we do this if required.

VIEW_REBUILD_DIR=E:\tmpdom\

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.

5
  • 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? Jul 14, 2014 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, 2014 at 8:07
  • Instead of an agent, did you try loading updall on a scheduled basis? Jul 15, 2014 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, 2014 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, 2014 at 11:20

0

You must log in to answer this question.

Browse other questions tagged .