Mobile Directory Catalogue
Mobile Directory Catalogue
March 24th, 2007, by Wouter Aukema.
Background
Two mail servers from a multinational, 80K+ user organization. One R6 mail server is located in Hong Kong, the other in Rotterdam, Holland. User (all on R5 clients) from remote locations have their mail file and R5 or R6 mobile directory catalogs installed locally on their client. They replicate with their country’s mail server. Users in an office where a mail server is located, access their mail file and MDC on the server.
Deployment of mail files and mobile directory catalog towards users while implementing local scheduled replication, raised concerns with respect to network availability. Network traffic over tcpip port 1352 prevented other types of (non notes-) applications from using the network.
DNA Network Analysis of average daily bandwidth consumption indicated high levels of activity in the early morning. The chart below is a standard DNA report.
The Assignment
The customer requested Trust Factory to analyze the characteristics of user behavior and corresponding network traffic in order to solve the lack of network availability.
Observations
Document Sizes.
The average size of documents for MDC type databases seems consistent for all locations between 10 and 15 kilobytes.
An interesting aspect is the fact that each MDC document contains summarized information of about 200 person documents.
Document Reads.
The chart below shows clearly how users from the two remote sites, during one week read a substantial larger amount of documents from the MDC. This is caused by the fact that thru local scheduled replication, all updated documents from the MDC are being received by the client, whereas clients that do not replicate only access MDC documents thru the type-ahead feature of the Notes client.
As the following chart indicates, each average user in Amsterdam is receiving up to 200 updates every hour between 0800 and 1100 hrs. Given a packing density of 255 this means that over 500 person documents have changed per hour, during that period.
This chart below shows that the average number of documents read for mail files is less for replicating users. This is because documents are read only once during replication. All other read actions are no longer performed on the server but on the client.
With respect to MDC access, we see that the number of documents read by replicating users is significantly higher.
Network Traffic Volume.
In the chart below, the overall network consumption per user location (being 100% in the chart, and total MB over the week) is plotted against each type of database.
Note how the network traffic from a both the release 5 and 6 MDC is causing 40% of all traffic, for sites that have mail and MDC installed locally on the client. Also, note how MDC traffic in Rotterdam and Hong Kong is less 10% of all traffic.
Mind that no conclusions can be drawn from the fact that R6 MDC traffic is lower than R5 MDC traffic, as only a limited number of users were using the R6 MDC.
The following chart shows the total amount of network traffic per hour, for each type of database. Note the peak in traffic resulting from MDC replication in Amsterdam, during the morning.
Leaving out the user mail file component, makes the picture more readable:
Number of Users.
The graph below shows per hour of the day, the number of users that are accessing the MDC, as well as the number of users sending mail into the server mailbox.
Note how in Amsterdam and Singapore (remote locations) the number of users accessing the MDC is always substantially higher than in locations where users access their mail on the server. This is caused by the fact that remote users replicate MDC, also receive updates of person documents they did not need for addressing email. Users in server locations (Rotterdam and Hong Kong) only access person documents thru the type-ahead feature of notes-mail, not accessing other person documents unnecessarily.
Bandwidth Consumption.
The effects of deploying an MDC locally towards remote clients, become very clear when the looking at bandwidth consumption during the day.
In the chart below, a calculation was made where the network traffic during per database type the day, was divided by the number of users active on the server during in the hour of the day.
It is interesting to see how bandwidth consumption per user in Amsterdam is substantially higher than in Rotterdam. The same goes for Singapore.
Due to a network failure, bandwidth consumption could not be calculated for Singapore in the period between 20.00 and 22.00 GMT.
Also, we see that users in Amsterdam use more bandwidth in the morning than in the afternoon, while in Singapore it seems more spread over the day. This is due to the fact that MDC updates are being generated in Asia. Local scheduled replication by users in Asia will cause these users to receive updates all throughout their working day. Overnight replication pushes all updates towards servers in the other time zones such as Europe. When users come to work in the morning, the Notes clients start to replicate all updates at once.
Conclusions
Based on the outcome of the DNA Network Analysis, Trust Factory came to a number of important conclusions:
1. With respect to user mail file deployment:
a. installing mail files locally on the clients, using local scheduled replication reduces the total amount of data being transmitted over the network;
b. installing mail files locally on the clients, concentrates the network load towards specific hours of the day, resulting in higher bandwidth requirements on those specific moments;
2. With respect to Mobile Directory Catalog deployment:
a. updates towards the mobile directory catalogs locally on the clients cause more than 40% of all network traffic towards those clients;
b. the savings in total network traffic resulting from local scheduled replication of mail files, is annihilated due to the additional traffic caused by the mobile directory catalog;
c. installing MDC files locally on the clients, concentrates the network load towards specific hours of the day, resulting in higher bandwidth requirements on those specific moments;
3. Local scheduled replication inhibits a flexible propagation of updates and network utilization that could otherwise be achieved by flexible replication schemes.
General Recommendations
1. When attempting to reduce network traffic, customers are advised not to base their decisions on estimated savings in traffic volumes. Analysis of system and end user behavior and actual bandwidth consumption in particular, is a much more accurate way to predict effects of change. Failure to do so, may lead to situations where large amounts of additional network capacity is needed at extra cost;
2. As a short term solution, prevent remote users from accessing the MDC during morning hours. A delay of half a day for publishing updates by means of the MDC reduces the overall bandwidth requirements with at least 40%;
3. As things are not working as it suppose to, customers are recommended to issue an enhancement request for the mobile directory catalog towards IBM;
Important
This document may contain or reference trademarks, patents, proprietary information, technologies, products, processes or other proprietary rights of Trust Factory B.V., its affiliates and/or other parties. No license to or right in any such trademarks, patents, trade secrets, technologies, products, processes and other proprietary rights of Trust Factory B.V., its affiliates and/or other parties is granted to or conferred upon you.
While Trust Factory B.V. uses reasonable efforts to include accurate and up to date information in this document, Trust Factory B.V. makes no warranties or representations with respect to the content of this document, which is provided "as is". Trust Factory B.V. accepts no responsibility or liability whatsoever arising from or in any way connected with the use of this document or its content. In particular, Trust Factory B.V. will not be liable for the accuracy, completeness, adequacy, timeliness, or comprehensiveness of the information contained on this document.
You must retain and reproduce each and every copyright notice or other proprietary rights notice contained in this document. You may not, however, distribute, modify, transmit, reuse, repost, or use the content of this document for public or commercial purposes, without written permission of Trust Factory B.V. You should assume that everything you see or read in this document is copyrighted unless otherwise noted and may not be used except as provided in the text on this document without the written permission of Trust Factory B.V. Trust Factory B.V. neither warrants nor represents that your use of materials displayed on this document will not infringe rights of third parties not owned by or affiliated with Trust Factory B.V.
With the exception of the foregoing limited authorization, no license to or right in any copyright of Trust Factory B.V. or of any other party is granted or conferred to you.