9
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.
