 |
Replication performance with network compression
by
Warren
White
Level: Intermediate
Works with: Notes/Domino
Updated: 05/01/2003
Related link:
More Performance Perspectives
|
|
The previously published Performance Perspectives column, "Network compression in Domino 6," presented an overview of the Domino 6 network compression feature. We talked about two different types of compression: network compression and attachment compression. Network compression, a new feature introduced in Notes/Domino 6, involves compressing data sent over the network using the LZ1 compression algorithm. Network compression is available on both the Domino server and Notes client. Attachment compression (as the name implies) compresses file attachments. R5 uses Huffman compression for attachments, while Domino 6 provides a choice of Huffman or LZ1 compression. The column concluded with test results showing that compression produced a 35 to 52 percent reduction in attachment size, depending upon the algorithm method used, with relatively small increases in CPU and memory utilization.
Since the publication of the earlier column, customers have expressed interest in determining how Domino 6 network compression affects replication performance. In response, we conducted a study comparing R5 replication with Domino 6 replication with network compression enabled over varying line speeds. This article summarizes our results. (For those who can't stand the suspense, Domino 6 replication provides a significant improvement both in terms of time and amount of data transmitted.)
This article assumes that you're an experienced Domino administrator.
Test setup
Our study examined client-to-server replication performance on R5 and compared it with Notes/Domino 6 with network compression enabled, specifically at line speeds similar to dial-up, DSL, or cable modem. Network compression offers two advantages: It buffers small messages and uses the LZ1 algorithm to compress all messages. Compression reduces the size of any message that can be compressed. A "compressible" message is any message that has uncompressed content, for example, text. This reduces the amount of data that needs to be transmitted.
Our test environment consisted of:
- Domino 6 and R5 servers, running on an IBM RS6000 H50 system with four 332 Mhz CPUs, 1 GB RAM, 2x4.5 GB drives, 40 GB RAID array, running AIX 4.3.3 fix pack 9
- Notes 6 and R5, running on an IBM M Pro XEON P3 with one 1.6 GHz CPU, 1 GB RAM, running Windows 2000
- The Cloud WAN Simulator, running on an IBM M Pro XEON P3 with one 1.6 GHz CPU, 1 GB RAM, running Windows NT 4 service pack 6
We created two test scenarios:
- Creating a new replica mail database containing 200 documents
- Adding 50 new documents to the same database via replication
Each scenario was run at 256 KBps and 56 KBps using Shunra Software The Cloud program to regulate line speed. The Cloud acts as a LAN/WAN simulator. We ran each test twice to ensure data accuracy.
We tested Notes/Domino 5.0.11 and pre-release Notes/Domino 6.0.1. The Notes client ran Windows 2000 replicating with an AIX 4.3.3 Domino server. This was a single user manual test. (The goal was to compare R5 to Notes/Domino 6 performance, not to load test the Domino server. We wanted to determine the effect Notes/Domino 6 has upon a single user replicating over a low bandwidth connection.)
We designed the comparison as a " version best case scenario" comparison with R5 configured to send Huffman compressed attachments and Domino 6 configured to send LZ1 compressed attachments with network compression turned on at the client and server. (Huffman compression is the default for both R5 and Domino 6.) Domino 6 has streaming replication by default as well. We used the R5 mail template in both tests. The mail database containing 200 documents was about 20 MB in size before updates and about 30 MB after 50 documents were added via replication.
The mail database consisted of text messages of varying size as well as a mix of text and binary (non-compressible) attachments ranging from 50 KB to 10 MB. Updates were also configured the same way with a variety of document types and sizes. We performed all testing on a private network to ensure that no other network traffic interfered with the test. Test data was collected using:
- An internal tool upon which Server.Load is based, used to write test scripts
- entstat (an AIX tool used for measuring network adapter statistics)
- Log.nsf used to view replication events, comparing time and bytes transferred
Note that the SendMail database we used to populate the mail in this test was created using ODS41 for R5 and ODS43 for Domino 6, the native ODS versions for each release. (LZ1 compression only works with ODS43.)
Results
Our results show a significant reduction in both amount of data transmitted and time to completion when using Notes/Domino 6 for client/server database replication. This was not unexpected because it obviously makes sense that sending less data should take less time. But we were pleased by just how much of an improvement we saw.
56 KBps test
In our 56 KBps tests, we compared R5 and Notes/Domino 6 performance in terms of our two test scenarios, creating a new replica mail database containing 200 documents and adding 50 new documents to the same database via replication.
Creating a replica
The first table lists the results of our 56 KBps replication test:
| Time to completion
(minutes) | Time improvement (percent) | Amount of data transferred (MB) | Data transferred improvement (percent) |
| R5 | 52.96 | | 19.38 | |
| Notes/Domino 6 | 29.13 | 45.28 | 11.86 | 38.84 |
Adding 50 new documents
The next table shows statistics for adding 50 new documents to the newly created replica:
| Time to completion
(minutes) | Time improvement (percent) | Amount of data transferred (MB) | Data transferred improvement (percent) |
| R5 | 20.04 | | 7.494 | |
| Notes/Domino 6 | 14.97 | 25 | 6.037 | 19.44 |
As you can see, in both tests Notes/Domino 6 provided a significant improvement in both time and amount of data transferred.
256 KBps test
The results of our 256 KBps tests were similar to our 56 KBps test—Notes/Domino 6 produced better performance than R5.
Creating a replica
The following table shows the results we obtained in our 256 KBps replication test:
| Time to completion
(minutes) | Time improvement (percent) | Amount of data transferred (MB) | Data transferred improvement (percent) |
| R5 | 12.61 | | 19.38 | |
| Notes/Domino 6 | 6.41 | 49 | 11.86 | 38.84 |
Adding 50 new documents
The final table lists the numbers for creating 50 new documents in the replica:
| Time to completion
(minutes) | Time improvement (percent) | Amount of data transferred (MB) | Data transferred improvement (percent) |
| R5 | 4.96 | | 7.494 | |
| Notes/Domino 6 | 3.26 | 34.27 | 6.037 | 19.44 |
Note that the amount of data transferred and performance improvement data are identical for both line speeds because the compression was identical in both scenarios.
Conclusions
As the previous tables show, there is an approximately 45 to 50 percent improvement when sending the new replica database with Notes/Domino 6 compared to R5. We also experienced a 25 to 35 percent improvement when updating that database with 50 documents. Of course, it helps when you are sending between 20 and 40 percent less data due to compression!
One thing you don't see in our results is the potential cost savings associated with the use of the attachment and network compression technology in Notes/Domino 6. You can download a PDF of a recent Ferris Research Report which concluded that network compression typically reduces Notes bandwidth requirements by more than 30 percent, producing potential cost savings in the range of $5 to $10 per user per month. In larger organizations, this could provide total cost savings in the hundreds of thousands of dollars or even more—a very significant sum. So network compression is likely to save you both time and money—a pretty good deal all around.
ABOUT THE AUTHOR
Warren White has worked in Product Introduction Engineering since 2000 on projects involving network compression, DEAS, iNotes, and spam filtering. He started at Lotus as a Support Analyst, moved to QE for Notes 4 and 4.5, then spent three years as a Field Engineer for Lotus Professional Services. |
 |