SnapshotCM Performance Tuning

"When you can measure what you are speaking about,
and express it in numbers; you know something about it;
but when you cannot measure it,
when you cannot express it in numbers,
your knowledge is of meagre and unsatisfactory kind."

-Lord Kelvin, 1895

Introduction

This article focuses on optimizing the performance of SnapshotCM by tuning both the SnapshotCM server and operating system configurations. The result we expect is improved throughput, reduced delays and increased scalability of SnapshotCM.

That said, it is worth understanding that perhaps the most important performance measure focuses on user goals, answering questions such as "What do we really need to do?" and "How quickly, reliably, and accurately can we do it?" While more abstract than "improved throughput", high-level goals can lead to new concepts and approaches to tasks which can dramatically improve a user's productivity.

An example from SnapshotCM illustrates this well: In file-based tools, such as CVS, a project state is remembered by setting a label in each file to remember the associated revision. SnapshotCM replaces this file-by-file series of operations with a "copy" operation - a familiar concept - that operates in constant time. The concept more accurately represents the goal. As a result, users can focus on the goal - remembering the state - without being distracted by the details of setting labels. User time has been optimized by a redesign of the concepts of the user interface.

However, our focus now is tuning SnapshotCM for improved performance. An example is increasing the speed of checkouts. At this level, tuning applies machine resources to improve some measure of performance.

One key to effective performance tuning is defining what one wishes to improve and how to measure it. Once you've defined a test and associated measure, you can run your test, make a tuning change and run your test again. The test results will show you numerically the effect of your change.

The remainder of this article discusses the effect of various resources on SnapshotCM performance. It is designed to give you basic guidance of which things to try first when tuning a SnapshotCM installation.

Performance Factors

SnapshotCM performance consists of a strict request-reply protocol. A client sends a request to the server and waits for the server's reply. The server responds only to client requests.

The execution cycle time for each request-reply consists of four components:

1. The time to transfer the data of the request and reply.
2. The round-trip overhead (i.e., request and reply delays due to network routing devices, as well as speed of light considerations)
3. The server processing time.
4. The client processing time.

The first two components will dominate in a WAN environment, and SnapshotCM has significant tuning to reduce the effects of network delays and bandwidth on client performance. In a LAN environment, server and client processing time are more likely to dominate.

The following resources affect the performance of SnapshotCM:

Memory

Perhaps the easiest and lowest cost improvement comes by increasing the memory in your server and/or client. SnapshotCM can cache most of your database in memory for fastest operation, and the operating system's file system buffer cache can optimize access to most revision content. If your disk is frequently busy, it's likely that more memory will improve performance of your system.

We recommend that the SnapshotCM database memory be configured to be greater than the total size of the database (z*) files. SnapshotCM will only use what is needed, so there is no harm in configuring an amount significantly larger than your actual database size. We also recommend that your total system memory exceed the size of the database memory plus the size of three or more full workspaces, to allow the file system buffer cache to cache the frequently accessed revisions. If you run other applications on a SnapshotCM server system, additional memory for the other applications is also required for optimal throughput.

Disk Speed

For database transactions, and for access to files that are not in the file system buffer cache, disk performance can have a significant impact on overall SnapshotCM server performance. Workspace update performance is also dependent on a user's workstation disk and file system buffer cache performance. Database transaction throughput is typically the limiting factor for import, check in and copy changes performance, so faster disk performance can improve the performance of these operations.

Note About Disk Write Behind Caching: Most systems support disk write-behind caching, which can significantly improve disk performance by reordering and grouping disk write operations. We recommend that disk write-behind caching be disabled for maximum reliability of the SnapshotCM repository database and archive files.

For maximum performance of the SnapshotCM proxy server, and since the proxy database holds no unique information that can not be recovered from the repository server, we recommend that disk write-behind caching be enabled for the proxy server.

Network

Whether your clients are local or remote, network performance is key to SnapshotCM performance. Most important is low latency, followed by high bandwidth. A low bandwidth and high latency network can be significantly aided by use of a local proxy server.

CPU Speed and Busyness

Faster CPUs and system architectures deliver improved performance and reduced response times for both server and clients. For best performance, we recommend a multi-CPU system for running the SnapshotCM server to allow true parallel processing, and server class hardware and operating system for optimum throughput with minimal overhead. We also recommend running the SnapshotCM repository and proxy servers on a dedicated system. Typically, a lightly loaded dedicated system will deliver better performance than a faster, but heavily loaded system.

Summary Recommendations

Below we summarize the recommendations for each of the SnapshotCM servers and client workstations. More detail on each recommendation is given in the above discussion.

Repository Server

The SnapshotCM Repository Server manages all information about your projects. Revision information is stored in the archive portion of the data store, and all other information is stored in the database (z*) files.

Recommendations:

1. Configure database memory to exceed the size of the z* files. (use cmconfig -C)
2. Insure you have adequate system memory as discussed above.
3. Disable write-behind disk caching for your repository server database and archive files.
4. Use a dedicated system for best performance.

Proxy Server

The SnapshotCM Proxy Server caches file revisions for a remote SnapshotCM repository server. Clients access the proxy server as they would the repository server. Most requests are transparently forwarded to the repository server. Requests to access cached file revisions are filled from the proxy server's cache without any access to the repository server.

Recommendations:

1. Configure database memory to exceed the size of the z* files. (use cmconfig -C)
2. Configure revision cache size sufficient to keep it from getting full.
3. Insure you have adequate system memory as discussed above.
4. Enable write-behind disk caching for your proxy server database and revision cache.

Client Workstation

The SnapshotCM clients manage user workspaces and all access to the SnapshotCM servers.

Recommendations:

1. Insure you have adequate system memory as discussed above.
2. Keep your GUI open, as it will incrementally update file status from the server. Whenever a new GUI is started, it must re-read all information from the server.
3. Enable write behind disk caching.

Conclusion

If you are seeking improved SnapshotCM performance, try these tuning suggestions. Don't forget what Lord Kelvin said over a hundred years ago, and be sure to quantify your performance before you make changes, so you know if you are making progress.

One more thing: Let us know what you find. Your experiences (and numbers) can help us improve SnapshotCM and this documentation. Cheers!

To see SnapshotCM in operation, get a free SnapshotCM evaluation at http://www.truebluesoftware.com/.