Write Latency Benchmark

This post will focus on the Write latency benchmark.

This benchmark is relevant mostly for trading applications that are required to submit a request into the backend system as fast as they can. The goal of this benchmark is to understand how much time it takes for a single write operation done by a single remote client to be completed over a fast LAN. This measurement does not necessarily mean how many write operations per second a client may perform (throughput). In fact these are 2 different measurements.

When building such a benchmark you need to take into account the accuracy of the CPU clock measurements, the JVM warm-up time (client and space JVM), the client proxy warm-up time and the space engine warm-up time.

The above means you have to perform some dummy space operations until the client and space JVM reach a “steady state” with their response time before you actually start measuring the response time.

The benchmark was built to measure the write latency with different write speeds (throughput rates). A client was pushing objects into a remote space where a sleep been called after X amount of write operations. This process was simulating throttling and made sure the client will have sustained correct write rate.

Each write operation time was measured by taking the time (in nanosecond unites) before and after the operation, where the best 80% of the results were used to calculate the average time of the write operation.

Here are the results of the benchmark:

The graph below includes results for 2 types of Space domain Classes:

– A Class with 8 fields where 3 of them are indexed (4 String Fields , 2 Long fields, 2 Integer fields). The class did not implemented Externalizable and did not had any special truing or optimization to deuce its footprint or speedup the serialization.

– A Class implements the Externalizable interface with non-implemented writeExternal and readExternal methods – i.e. empty object (acting as a control dummy). Since this is the fastest manner to push data into a remote space, it will allow us to measure the overhead of the object serialization and marshaling when converted from a POJO into a space object.

– The results illustrate 0.29ms latency for a remote write call operation to be completed for a non-replicated space.
– As a comparison – empty object write latency is 0.27ms for non replicated space.
– When the space is sync replicated it adds an overhead of 130%. The 8 fields object write latency is 0.69ms and the empty object write latency is 0.63ms.

The benchmark has been conducted over 1G network with 0.208ms round trip ping latency for 1K object. This means that GigaSpaces overhead on top of the network latency is about 0.1ms. Very impressive!

System Environment:
OS: Sun Solaris 10 x86-64
Architecture: 4 x AMD Opteron Dual-core 8220 2.8Ghz
RAM Size:16GB
Machine Type:Sun Fire X4600
JVM: Sun java version “1.5.0_07”
Interconnect: Gigabit Ethernet

Shay