Assessing the impacts of new transaction logging features by Jim Powers

Level: Intermediate Works with: Domino 6 Updated: 05-Jan-2002

Transaction logging is an important server reliability feature, and many R5 administrators can tell you first-hand about its benefits. With Domino 6, we're introducing several enhancements to transaction logging for even better reliability.

This month's column looks at several of these new transaction logging features and discusses their performance impacts, based on our internal performance analysis. We want to share this information with you now, so you understand how these new features may impact your server performance and so you get a headstart planning your Domino 6 deployment.

Specifically, we looked at the impacts of three features added to Domino 6 to improve performance:

• The new lock manager is designed to help performance by only locking down those database elements required for a function rather than locking the whole database. This allows multiple operations on a database at the same time, for example, read access while doing writes.
• The improved flush algorithm flushes the buffers (writes data to the databases) more often, which causes shorter interruptions when the database is locked for write access.
• View logging is a new feature that allows transaction logging of view elements. Its purpose is to give faster access to a database with complex views after a crash by preserving the view information in the transaction log and eliminating the need for a view rebuild. This feature does come with some performance cost, although minimal, and so should only be enabled on complex views where a benefit will be realized. This feature is enabled per database view using the Domino Designer client.

Assessing performance impacts
To assess the performance impacts of these new features, we used the NotesBench R5Mail workload on an IBM Netfinity 8500R P-III Xeon 8-way 550 MHz server with 4G memory running Windows 2000. Using a Domino R5 and a Domino Pre-release 1 build, we ran the Domino NotesBench R5Mail workload. (See the R5Mail workload sidebar for a list of what this workload consists of.)

New lock manager and flushing algorithm
Running this workload on an R5 server with transaction logging enabled in favor runtime mode, we could emulate what many of our customers with busy systems have seen with R5. Initially, the response time is great, slowing only during a transaction log flush period. As more users are added and more transactions happen, the flush periods become more frequent, causing the overall response time to worsen. You can see this in the following chart by following the response time (green) line. Notice that as it approaches 6,000 users, respone time has reached 250 milliseconds. This occurs because the transaction logging logic has reached a state of almost constant flushing, locking the mail databases more often to do its updates and not allowing users access to the databases at that time.



In contrast, running Domino 6 with transaction logging, the effects of the new lock manager and new flush algorithm are evident. With these new features, the databases can still be accessed during a transaction log flush, so there are no long response spikes. The result is a substantial improvement in user response time even at 6,000 users, as shown in the following chart.



View logging
To test the performance impacts of view logging, we used the Domino NotesBench R5Mail workload and enabled view logging on the Inbox folders of all 10,000 users. Even though the Inbox is not a complex view, using this test workload produces a large number of view changes and increases transaction log work.

Once again, the results were favorable. Even with the added load, we saw only a 10 percent CPU utilization increase, and the difference in user response time was negligible. If you combine this slight reduction in response time with the obvious improvement in recovery time that view logging achieves, particularly for complex views, the overall impact of this new feature is positive. Obviously, exact results depend on the view being logged; many views will show even less of a increase in CPU utilization.

Note: This is a good example of where test conditions and resulting data analysis don't always translate into recommendations for production environments. Using view logging on 10,000 user Inboxes was done as an exercise of a new feature to ensure various criteria were met; it is not a recommended implementation strategy. In production environments, we recommend that view logging be turned on only in key databases and key views.



Conclusion
From this preliminary assessment, we concluded that the three new transaction logging features in Domino 6 we evaluated do not negatively impact performance. In fact, the new lock manager and flush algorithm help offset response time issues that R5 clients may have seen with transaction logging enabled. And with its negligible performance impact and large recovery time reduction, view logging presents an overall improvement for your servers.

For more information about transaction logging, see:

• The Iris Today interview, What's in store for the Domino 6 database, which describes the new database features in Domino 6, including the new transaction logging features
• The Compaq Backup/Restore for Lotus Domino, Best Practices White Paper
• The IBM Redbooks: Lotus Notes and Domino Take Center Stage: Upgrading from R4 to R5, (SG24-5630-00) and Lotus Domino for S/390 Release 5: Performance Tuning and Capacity Planning, (SG24-5149-02)