As an example, the problem with slow View Update performance becomes most visible with large domlog.nsf or large log.nsf NSF databases.
If there are several million documents, and if several documents are added per second, the View Update may take too long, or the View will "never" open.
Apparently, updating a View seems to be a single-threaded process. If too many documents were added/changed, the Update task will initiate a full View Rebuild, which makes it even worse.
This model limits NSF-based applications to scale per se.
Typical workarounds to this weakness are to use faster storage, or to distribute data accross more databases, which have a smaller amount of documents.
I believe that it should be possible to raise this limitation substantially by introducing a multi-threaded View Update model (multiple threads working on updating a single View in parallel)