Server And Object Directory Optimisation; Endpoint To Server Communication - Network Load Estimation; Estimating The Size Of The Object Directory - McAfee ENDPOINT ENCRYPTION ENTERPRISE - BEST PRACTICES GUIDE Manual

Server and Object Directory Optimisation
Endpoint to Server Communication ‐ Network Load Estimation
Endpoint Encryption network traffic is the easiest to consider in terms of "synchronization events". Each time a
system starts it tries to connect to a designated EEPC database communication server and update its profile. It
may also (depending upon configuration) try to connect periodically. In large deployments, the first step in
estimating the network load caused by Endpoint Encryption is to estimate the peak number of concurrent
synchronization events. This is related to the user working practices. For example, if 2000 users switch their
systems on at 9 A.M, the "9 A.M." effect can be diluted by setting optional boot sync delay and offset times to
spread the load across, for example one hour.
Once peak flow is estimated, double it to give some safety, then work on an estimate of 7 KB per user per sync
(this is a very high approximation based on total update of the user every two sync events). A typical Windows
server, in our experience, can accept 100 connections per second per server, with a default maximum wait
time of 30 seconds for pending connections.
The maximum capability of a single Communications Server, taking the capacity of the network to be 100
Mbps (1 million bits per second) is 20 synchronizations of data a second. A Windows server OS can establish
connections about every 10ms, and can handle unlimited connections (although eventually it will run out of
clock cycles and memory).
Once established, a connection can take an unlimited amount of time to finish, though the default timeout on
establishing a connection is 30 seconds. If there are more than 100 attempted connections per second, the
queue cannot be longer than 3,000 connections.
The default settings of the Communication Server limit the queue to 200 entries (a balance between taking
connections and processing connections). After that point, the connections are refused. This is a reasonable
"real world" setting. As long as the profile of the system is set to retry the connection after, for example, four
hours, there is no loss of function. Setting the queue length to more than 1500 can result in poor performance
from the server as it tries to service so many connections.
In real terms we can say that as a general maximum case, the Endpoint Encryption Server is limited to 100
connections per second, with a sustained load. Saturation in our experience is reached when there is more
than 1400 synchronization events per minute (1200 accepted and processed, 200 queued). Achieving this load
in the real world requires a massive, badly planned and configured population of systems. Current customers
with 40000 + installations rarely exceed the 200 current connection points, most of which are administrators
performing configuration changes.
The operating system or disk controller caches most of Endpoint Encryption's database, so eventually the
common files will be supplied from RAM rather than across the connection to the database host, or, from disk.
Using the compressed version of the database can improve performance by a small amount, however, it is
useful when corporate backup software has difficulty archiving the database.
This rough calculation tells us that we need one Endpoint Encryption Server per 1400 events a minute
minimum; however, experiencing the system in action will give true feedback. It is often the case that modern
hardware outperforms paper estimations.
Estimating the Size of the Object Directory
The base size of an Endpoint Encryption 5.x Object Directory is around 150 MB. Because you add new users
and systems, the ODB grows accordingly. It also grows in size as systems synchronize and upload audit
information.
9