I have spent many years working deep within the Notes Indexing Facility (NIF). I’m not done, because there is more to be done and harvested from the rich functionality well-bundled from day one by the earliest Domino developers. It can be a challenging area because so much variety of data flows through the code and onto the glass. If one is not careful, you will make one user story a delight while another becomes quite less so. 

One of the most problematic operations in NIF is its handling of updates. Someone could say “Well, what is the problem? Other database products have no issue updating their indexes, why is Domino any different?” The answer lies in the ease with which views and folders are created in Designer. It is a very common story that views constantly grow in number and complexity. 

So, I often reply to the question of the difference this way: “If you went to your MySQL or Oracle or DB2 or MongoDB administrator and asked for 200-1000 indexes on your database, what would they say?” Of course, they would laugh you out of the room, as they should. Yet, that number of indexes is quite normal on a Domino database and it is why they are updated lazily, on a scheduled or as triggered or forced. There are a variety of update/refresh rules and I will not go into them here. 

Some of the costliest issues with NIF are due to excessive queueing for updates. Most of the APIs and documentation call it “refreshing” when a user opens a view and wants to see the latest updates, which is completely reasonable. The trouble what when a large number of users (well, threads) do that at once, they each compete for the right to update the view in a “fair read/write” queue – that is, those who only want to read get no preference over writers (we don’t starve updates). The result can be a breach in Service Level Agreement (SLA) timings and opening a view simply takes too long. 

Following is a diagram I put together for SPR JCUS8MXLA2. Included in the mix is the “Update Task” representing scheduled, dedicated view updating: 

You may or may not know that in the v9.01 feature packs, Domino development rather quietly produced a feature to attack this problem. It is called “inline view updating” or just “inline.” You can toggle it on via

load updall <database name> [-T <viewname>] -inline on/off

What this does is to apply view updates at time of document updating. All refresh requests at view open time can therefore be treated as nops, as they are. Document updating becomes a heavier unit of work, but the view open and read performance trade-off is worth it.

A second effort was launched in Domino V10, which detects and then automatically creates a dedicated update thread to high usage views. It is enabled via NIF_VIEW_USAGE_ENABLED=1 in notes.ini.

I wanted to measure the effect of the first effort, -inline, so this summer at HCL Chelmsford (well, at home due to COVID-19) I’ve had the privilege of working with an intern in core Domino, Joseph Calles. I set Joseph on a quest to provide real timings with -inline on and off. He wrote some scripts that allowed him to vary the read vs update load against a 200K document database with three views and collected stats using “show trans” at the Domino console. Joseph capped the document update and view operations at 10/second, but of course your numbers will scale according to volume, bulk of data and hardware utilized.

No one is claiming these numbers are real-world, the data and processing is automated. But they are consistent relative to the gathered set. And they show some trends people should know about as they consider using -inline. The variance in test load was simple: for each run, the number of all operations was incremented by one per second.

The OPEN_COLLECTION transaction is what bogs down trying to update a view when inline is off. The benefit is very clear to see in the first graph, and it should be noted that without inline, time to open a view increases much faster than linearly. That .. is the log jam I mentioned.

In the second graph, open view and read view entries are combined to provide a single duration. This is close to what a user would experience opening a view and getting his/her first window of entries rendered. Again, the spike with larger numbers of transactions without -inline is clear.

Now, very few SLAs will be violated with 800 millisecond response. Again, the point is the curve. Showing maximum time to open a view shows the erratic, worst-case user experience, which would indeed violate most SLAs (note, times are in seconds in this graph):

Truth in advertising — document update times do increase with -inline on, but you would expect them to. And they don’t increase exponentially but linearly. But don’t confuse this with a decrease in throughput — it is not affected, only time to complete:

This final graph treats all operations — update, finds, view opens and view entry reads equally and averages their combined duration. So, overall duration impact of -inline processing if you will:

But it’s important to remember the original use case — multiple users trying to open and read a view but first “refreshing” (that is, updating). With -inline on, the refresh operation is unnecessary since any view being read is updated during a NSFNoteUpdate operation. So those view open operations are much lighter weight.

To say it again, this behavior is “normal” for transaction-centric database systems, especially the relational variety where data lives in neat rectangles (ok, they have progressed a bit). But in Domino, a document-storing and -processing NoSQL engine that supports so many different indexes constructing index data so many different ways, a lazy update model is appropriate lots of the time. And the -inline feature addresses those cases where it is not appropriate.

So, if you have contentious views — and please, not all views are hotly contended for — I recommend you strongly consider turning on inline view updating, using

load updall <database name> -inline on -T <name of contentious view>

And reap good benefit.

I would beware of turning it on for all views in a database as the document update cost could then surge. You know your most contentious views; tackle those first.

Comment wrap
Further Reading
article-img
Digital Solutions | June 11, 2021
Announcing the Domino REST API Beta Program  
Today, we’re announcing the start of the beta program for our new Domino REST API, formerly known as “Project Keep.” This is the latest addition to our ongoing Domino Early Access Program. The Domino REST API will introduce hundreds of new APIs that aperture to information on Domino — further extending access to your Domino data. It’s a modern take on the REST API for opening Domino access to a world of standards — and API-first developers. What is it?   Domino REST API is a new feature that runs alongside the server and allows you to expose your Domino data in the form of standardized Open-API-based methods securely and easily. Using a browser-based admin UI, application owners can define which data will be made available for view or update on a REST API. It extends the Domino principles of reader/author document access definitions into the world of Internet protocols.  It also includes Swagger UI which allows the visualization and interaction with APIs without having any of the actual implementation logic in place. The APIs are automatically generated from an OpenAPI (formerly Swagger) specification with visual documentation, making it easier to later implement the back-end code.  What is special about the new Domino REST APIs?  Secure by default, with fine granular controls per form, field and user basis  Implements latest open standards  HTTP/2-ready, for server-to-server or client-to-server communication API-first design with full interactive documentation  Low barrier to entry as it runs on a Domino server and/or your Notes client  Admin UI and Postman samples included  State-of-the-art JWT access token integrated with your existing IdP infrastructure What can be accessed via the Domino REST APIs? You can access content like views, documents, and fields, as well as database design, agents, and ACL settings. And, of course, featuring DQL queries to quickly access the data you are looking for.  Built-in declarative security ensures the API will only allow access to fields the caller is authorized to see or update. This can effectively prevent computed fields to be overwritten and limits participants in a workflow to update their fields only.   How to participate   The Domino REST API is now available as a...
article-img
Digital Solutions | June 7, 2021
HCL SafeLinx 1.2 is Live with Nomad Web
We are pleased to announce the release of HCL SafeLinx 1.2 for general availability. Starting today, customers can try out new features by downloading the package from Flexnet. In the past few months, we have been focusing on providing you a more user-friendly enterprise VPN platform with reverse proxy capabilities which aims to boost your middleware security at work.  SafeLinx and Nomad web  As part of the Domino v12 launch, this version comes with improved functionalities for Nomad Web Proxy:  New resources container specifically for Nomad, inherited from the generic http access service but only providing attributes needed for NWP  Modified initial configuration wizard to streamline NWP creation as part of initial setup  Ability to serve the Nomad web application static files directly from SafeLinx (event driven), without the need for an additional http server  Support for HCL Verse application integration when the Nomad app launches from a mail link  SAML as an authentication option  Configurable buffer size for NRPC flow  Configurable attribute for querying the User CN to use in Nomad client configuration.  Nomad-branded login screens  Other new features of this release include support for Mac OS administrator, MS-SQL Linux, and My SQL (Linux and Windows), and a new splash screen. To see the full list, please refer to SafeLinx 1.2 release notes.  Getting started: pricing and licensing For Notes/Domino Complete Collaboration (CCB) customers, SafeLinx is now available as a FREE entitlement and will be listed under supporting programs. CCB customers can use SafeLinx’s server component without the need for an additional VPN client to securely access their Domino apps from mobile. With this release, we’d like to provide our customers the opportunity to evaluate SafeLinx VPN for broader usage. Please contact your HCL Software representative or HCL Business Partner for more information on how to get SafeLinx 1.2.  SafeLinx is also available as a standalone to non-Notes-Domino Complete Collaboration customers. Contact us for more details. Our team has put in many hours turning your ideas into reality and we’d love for our customers to continue submitting ideas and improvements in our Ideas Portal. (Make sure you select “SafeLinx” under the Workspace before submission.)  Domino v12 Launch Missed the v12 live event yesterday? The launch is not over! We’ve just started rolling out the Domino Dozen which includes 12 days of...
article-img
Digital Solutions | June 3, 2021
Making a Smooth Upgrade to HCL Notes v12
The big day is coming soon! HCL Notes / Domino v12 will be launched  globally on June 7th (it’s already available for download on HCL FlexNet since May 27th). For those customers planning to upgrade, we have some great news. Whether you have been keeping pace with the rollouts of new HCL Notes client versions, or are WAY behind, there is a path for a seamless and smooth transition to v12. The MarvelClient Upgrade solution empowers organizations to optimize their HCL Notes client management and standardize all client versions with a consistent configuration during the automated upgrade process.  Common Upgrade Challenges What we have heard consistently from organizations around the world is that they want to reduce the complexity of their HCL Notes client installations and lessen the administration support tasks required. It is an ongoing challenge for IT support groups to keep pace with the upgrade cycles provided by their vendors. The following list is a showcase of some challenges that organizations face during an upgrade process:  Creation of Notes Client Install Package (with standard configurations)  Upgrade Package Deployment for Remote Users (with or without VPN)  Installation / Upgrade Process Execution Trigger for Automation  Migration of Notes Data Folder  Automated Upgrades for Different Deployment Models (Laptops, Desktops, Citrix, VDI, different OS versions, etc.)   The MarvelClient Upgrade solution handles all those requirements and more. The centralized tracking and reporting environment allows administrators to monitor the client deployments for all employees. And if any modifications are made through user error, they will be rectified and reset to the standard, supported settings on the next restart of the HCL Notes client. These automated, self-healing functions enable any organization to ensure a consistent environment for their users and reduce the number of IT support calls from HCL Notes client installation issues.  In addition, the MarvelClient Upgrade automates the entire process. This makes it easy to perform regular upgrades in the future as new software versions become available. If your organization is preparing to upgrade HCL Notes/Domino in the near future, please access this best practices list to avoid common project pitfalls.  Review of HCL Notes / Domino v12 We recently hosted a co-webinar with an expert from HCL on April...
Close