Although a major
functionality of eXtreme Scale is its
ability for elastic scaling, it is also important to consider sizing
and to adjust the ideal number of CPUs to scale up.
Processor
costs include:
- Cost of servicing
create, retrieve, update, and delete operations
from clients
- Cost of replication from other Java™ virtual
machines
- Cost of invalidation
- Cost of eviction policy
- Cost of garbage collection
- Cost
of application logic
- Cost of serialization
Java virtual
machines per
server
Use two servers and start the maximum
JVM count per server. Use
the calculated partition counts from the previous section. Then, preload
the
Java virtual
machines with enough
data to fit on these two computers only. Use a separate server as
a client. Run a realistic transaction simulation against this data
grid of two servers.
To calculate the baseline, try to saturate
the processor usage. If you cannot saturate the processor, then it
is likely that the network is saturated. If the network is saturated,
add more network cards and round robin the Java virtual
machines over the multiple network
cards.
Run the computers at 60% processor usage, and measure
the create, retrieve, update, and delete transaction rate. This measurement
provides the throughput on two servers. This number doubles with four
servers, doubles again at 8 servers, and so on. This scaling assumes
that the network capacity and client capacity is also able to scale.
As a result, eXtreme Scale response
time should be stable as the number of servers is scaled up. The transaction
throughput should scale linearly as computers are added to the data
grid.