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