Network compression is an important performance feature offered in Notes/Domino 6. When you enable network compression, data is automatically compressed before it is sent over the network. This improves network performance, especially over slower line speeds.
Notes/Domino 6 network compression offers a number of immediate benefits. For example, by reducing the amount of data being transmitted, you can improve the performance of your routing and replicating hub servers, especially if they're currently laboring under heavy workloads. And you can enable it by default, so all your users can take advantage of this functionality without having to select it themselves. Because network compression is a standard, out-of-the-box feature, it doesn't require any additional code, which helps simplify administration and requires fewer CPU resources to run.
Of course, as with any new functionality, network compression raises some immediate questions:
- Just how much network bandwidth do you save with compression?
- How does network compression affect server performance?
- Do you need this new feature if you're already using R5 attachment compression?
- How will this work with encryption? Can encrypted data be compressed and decompressed?
To help answer these questions, the Lotus Product Introduction Engineering team conducted a study of network compression, using a variety of different configurations. The purpose of this study was to simulate as closely as possible real-world customer sites and determine typical results of using network compression. This article discusses the results of these tests, and you'll see that these numbers show significant bandwidth savings when you enable network compression. But before we "give away the ending," we'll briefly describe how network compression works and how it relates to the existing R5 attachment compression feature. Then we'll explain how we conducted our tests and the results we obtained. And, in the spirit of full disclosure, we'll also describe how enabling network compression affected the servers on which we ran our tests.
As you read these results, bear in mind the numbers and trends we derived were based on data obtained through in-house testing. No amount of testing, however, can fully duplicate every possible customer environment. Our results are valid and useful for comparison purposes, but of course they don't guarantee all customers will experience the exact numbers and percentages we did. As they say in TV commercials, "your results may vary."
This article assumes you're an experienced Domino Administrator.
How network compression works
Network compression is performed by the NRPC (Notes Remote Procedure Call). NRPC compresses the data before it is transmitted over the network, using the LZ1 algorithm developed by Abraham Lempel and Jacob Ziv. For detailed information on the LZ1 algorithm, see the IBM paper, A fast hardware data compression algorithm and some algorithmic extensions.
In Domino 6, you can enable network compression using the Notes client and/or the Domino Administrator.
- Open Notes, and choose File - Preferences - User preferences.
- Click the Ports tab.
- Select the port on which you want to enable network compression from the list.
- Click the Compress network data checkbox. This enables network compression for the selected port on the local Notes client. (This does not affect the server.)
From the Domino Administrator:
- In the Server pane, click the server on which you want to enable network compression.
- Click the Server - Status tabs and then click Server Tasks.
- Under Tools on the right, click Server - Setup Ports.
- Select the port on which to turn on network compression. (Make sure Port enabled is selected for the port.)
- Select Compress network data.
- Click OK.
- Restart the ports on the server so that network compression takes effect. This enables network compression for the selected ports on this server. (This does not affect the Notes client.)
With network compression enabled on both the sending and receiving computers, the Notes client and/or Domino server will attempt to compress any data (for example email or replicated documents) before transmitting it over the network. Network compression works with mail routing, replication, or any other data sent via NRPC. This includes design elements in new or updated replica databases.
Several factors might affect compression:
- Network compression works for both Domino-to-Domino and Domino-to-Notes sessions. Both the sender and receiver must be running Notes/Domino 6 and have network compression enabled. Otherwise the data will be sent uncompressed.
- Data that is first encrypted cannot then be compressed. However, data that is first compressed can then be encrypted. With Notes/Domino 6 this is not an issue. If you use port level encryption in Notes/Domino 6 combined with network compression, then network data is automatically compressed first and then encrypted. When you do this, you receive the full benefit of both compression and encryption.
- Network compression cannot further compress an already compressed attachment. This includes files compressed by Notes when attached (Huffman or LZ1 attachment compression) or in a compressed file format (such as a zip archive or jpeg). In other words, once a file attachment is compressed, it can't be further compressed by network compression. This is an important point to remember when determining the results of network compression at your site. If you run a test in which you mail a large number of compressed attachments, the resulting gains produced by network compression might appear smaller compared to mailing documents with uncompressed attachments. (We further illustrate this fact in the test results that follow.)
While we're on the subject of attachment compression, this feature has been enhanced in Notes/Domino 6. Attachment compression can now take advantage of the LZ1 algorithm (the same algorithm used in network compression). In R5, attachment compression used the Huffman algorithm. To use LZ1 attachment compression in Notes/Domino 6, you must enable it in the database properties. (By default, databases still use the Huffman algorithm to maintain backwards compatibility with previous versions of Notes.) In related testing, we determined that LZ1 attachment compression typically reduces attached file size by a further 5 percent to 40 percent over Huffman attachment compression in Notes. (This number varies widely depending upon the type and complexity of the file attachment being tested.)
Network compression test results
We conducted a study of network compression by running a series of tests with both mail routing and replication. The purpose of this study was to examine the effects of network compression on:
- Network bandwidth saved (in terms of the amount of data being transmitted) both with and without attachment compression enabled
- Overall impact on server performance (CPU and memory usage)
All testing was done on Domino 6 beta servers running the AIX operating system and Notes 6 beta clients running Windows NT. The remainder of this section discusses these results.
Network bandwidth: 50% off!
We ran three different types of tests to determine how much network bandwidth can be saved with network compression, and we obtained consistent results. In the first test, we used client-to-server replication on an isolated network with no traffic other than the test client and server. (This helped ensure the results weren't skewed by extraneous network traffic.) We used AIX's Netstat utility to measure network traffic at the server's network adapter.
We replicated three types of databases. Each database contained 1,000 documents with a mixture of text-only documents (no attachments), documents with text attachments, and documents with binary attachments. (This simulates pre-compressed files such as zip archives and jpegs.) For the first database (which we'll call db1.nsf), none of the attachments were compressed with attachment compression. This database totaled 106.10 MB, and contained the following:
|Document type||Number of documents||Total size (MB)|
|10 MB text attachment||5||47.69|
|50 KB text attachment||42||5.56|
|50 KB binary attachment||58||4.03|
|No attachments (text only)||895||35.98|
|Database design, session, misc.||13.57|
The second database (db2.nsf) contained essentially the same 1,000 documents. This database had R5 (Huffman) attachment compression enabled. As a result, db2.nsf was 81.36 MB in size. The third test database (db3.nsf) also had attachment compression enabled, but used Notes/Domino 6 (LZ1) compression. Db3.nsf was 79.25 MB. (The difference in size between db2.nsf and db3.nsf is an indication of the efficiency of LZ1 compression. However, because text attachments are not very complex, Huffman compression was nearly as efficient as LZ1 compression in this example. In cases where more complex attachments are used [such as spreadsheets, word processor documents, or presentations], LZ1 achieves significantly higher savings over Huffman.)
We pulled new replicas of each database from the server to the client and also pushed new replicas from the client to the server. We performed each test run multiple times to ensure consistency and accuracy. The results, which we derived by examining the log.nsf database described later in this article, were very consistent. When we totaled the numbers, we found network compression reduced the amount of data transferred by the following percentages (all numbers rounded off for clarity):
|Database||Size before network compression (MB)||Size after network compression (MB)||Percent reduction|
|db1.nsf (no compression)||106||51||52%|
|db2.nsf (R5/Huffman compression)||81||54||34%|
|db3.nsf (Notes/Domino 6/LZ1 compression)||79||52||35%|
As you can see from the results, network compression has a significant impact on the amount of data being transmitted over the network. Indeed, when we used network compression on documents with no compressed attachments, network compression reduced the amount transferred by approximately half. Needless to say, this should be welcome news if your site employs slower or overused network connections.
It's also important to consider the figures we obtained when we used network compression with attachment compression. At first glance, it may appear attachment compression makes network compression less effective, because the reduction is around 35 percent with attachment compression enabled and 52 percent without it. Looking a little more closely at the numbers reveals this isn't the case. Once an attachment is compressed, it can't be compressed a second time. (Too bad, otherwise you could just run nested compression routines and reduce a file down to a single byte.) Thus, when you enable attachment compression on a database, network compression will only work upon the uncompressed data. Attachments already compressed via attachment compression are sent over the network without any further reduction. So perhaps the most important portion of the above table is the third column, Size after network compression, which contains very similar numbers. Remember that all three databases had the same documents and attachments and so the same original size (before attachment compression) of 106 MB. The third column shows that compression-whether done solely through network compression or through a combination of network and attachment compression-reduced 106 MB of data to somewhere around 50 MB, or by approximately 50 percent. This is a major savings in network bandwidth no matter how you look at it.
In a second test, we enabled network compression for server-to-server mail routing. In this test, we used a similar set of documents but all had Notes/Domino 6 LZ1 attachment compression enabled. The documents were then routed from one Domino 6 server to another and then delivered to Notes 6 mail users on the second server. We ran the tests at three different network speeds: 256 KB, 56 KB, and 33.6 KB per second. The overall amount of data reduction was similar to the numbers cited above. In this test we also looked at the amount of router time saved with network compression; it averaged approximately 26 percent.
Finally, we ran a third test with a "stressed" Domino 6 server with network compression enabled. This scenario contained users who were sending and receiving mail as well as replicating. The performance results of this test are discussed in the next section. But it is interesting to note that this test also yielded comparable numbers in terms of network bandwidth saved: 47 percent (without attachment compression).
As we mentioned at the beginning of this article, your results may differ from ours, depending on many factors-hardware and software configuration, topology, workload, and so on. Nevertheless, we feel the conclusions drawn from these tests are consistent and clear. Whether used by itself or on conjunction with attachment compression, network compression saves a significant amount of network bandwidth.
Server workload with network compression
Someone once said "There's no such thing as a free lunch." This holds especially true for computer software, where every major advance in functionality seems to bring with it at least a little cost in computing power. Network compression is no exception. When a server is running Domino 6 with network compression enabled, it takes a certain amount of computer cycles to compress data, send it over the network, and decompress it after it's been received.
To help determine how many cycles, we conducted a detailed test, using an internal load testing tool similar to NotesBench and Server.load. This tool simulates end user behavior in a Domino environment. In our test, we produced a workload equivalent to:
- 804 total concurrent users who are using mail, replication, and full-text index
- 3,800 total registered users
- Average mail file size of 69 MB
- Server-to-server mail routing
Enabling network compression on all Domino servers and Notes clients in our test environment reduced network bandwidth by 47 percent. It did, however, have some impact on server resources. CPU utilization increased by about 7 percentage points on our test server when we enabled network compression. Also, memory allocation by the Domino Server tasks increased by 15 percent. We examine these results in more detail in the following sections.
Without network compression, CPU utilization averaged 63 percent with our baseline load of 804 concurrent users. When we enabled network compression, the CPU average rose to 70 percent.
Figure 1. CPU utilization with and without network compression enabled
This increase affected each Domino task differently. The tasks that increased the most in CPU utilization were the Server and Router tasks. Interestingly, the Replicator actually dropped slightly in CPU usage, possibly due to shortened session time required to transfer the compressed data. The following table displays the effect of network compression on the "heaviest" server tasks, in terms of CPU usage:
|Process||Cumulative CPU time without compression||Cumulative CPU time with compression||Percent increase|
We also tested the effects of network compression on server memory allocation. Without network compression, our test workload yielded a memory allocation of 1.66 GB. With network compression enabled on the server and all other computers in our test, memory allocation rose to 1.9 GB, an increase of approximately 15 percent. As with CPU usage, memory usage of each server task was affected differently. The tasks most affected were the Server and Update tasks. And once again, the Replica task showed a small decrease in memory allocated.
Network compression: by the numbers
There's always a danger in reading too much into the numbers-remember the old saying about "lies and statistics"? Nevertheless, our test results indicate quite clearly that you can expect a significant saving in network bandwidth with Domino 6 network compression-as shown from our example, possibly up to 50 percent when transmitting uncompressed attachments. Your site may produce different figures, so you may want to do your own testing and analysis. To help you do this, we've added two new columns to the Domino 6 Server Log database (log.nsf):
- KBytesUnComp shows the total number of bytes of the data before network compression
- KbytesComp shows the total number of bytes after network compression
You can determine the overall impact of network compression by comparing these two columns. To do this, you must upgrade the design of your Server Log database with the Domino 6 version of log.ntf. (For more information, consult the Domino Administrator 6 Help.)
When you do your tests, be sure to take into account the effects of attachment compression, which may make it appear as though network compression isn't as effective. But whether you use network compression by itself or in combination with attachment compression, the amount of data transmitted over the network should be approximately the same. And look closely at the impact on server performance, both in terms of CPU and memory usage. You may need to carefully weigh the benefits of network compression against resource utilization, especially on slower or overloaded servers.
For most sites, network compression will likely be an important tool in the administrator's arsenal. In an increasingly online world, network speed is quickly becoming a precious commodity. Network compression can help ensure your network is as fast and high-performing as possible.
Dig deeper into IBM collaboration and social software on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.