Navigation

Home

SourceForge Home

Articles on Java

Getting Started

Introduction

Javadoc

Essence Documentation

Benchmarks

Browse Source

All classes Javadoc

Fisheye Analysis

Code Coverage Reports

Essence Roadmap

Download

Essence Latest

Essence JMS Sample Application

Contact

Get rewarded for helping out

Email A Question

Weblog

Summary

These tests give an indication of performance based on a synthetic benchmark. The performance of a real program in real world situation is always likely to be less than what is provided here. IMHO, Until you test your application on the target machine with real world workload, you should allow for 5-10 times less performance than a synthetic benchmark.

Essence 0.68 has been tested with 2-way and 4-way mastering (were each update is committed to both or all 4 servers) and persisted to disk in near real time.  On a Linux blade, the tests performed 9,700 to 120,000 updates per second depending on the transaction size.

The tests performed 60,000 updates per second and 6 million lookups per second concurrently in 2- way durable mastering mode. In 4-way durable mastering mode, the tests performed 24,000 updates per second and 2.4 million lookups per second.

Benchmark results

In one of the unit tests, a four master configuration is tested. The tests are performed with persistence turn on and turned off. In each test, each master updates one quarter of 65,000 price objects. These objects have an instrument (java String), a time stamp (java long) and two price values "ask", "bid" (java double). The average size of an update is about 40 bytes on the wire due to the efficient object serialization. It is assumed that the network impact is minimal for this size of packet. For each update, a number of lookups are performed. For 50% lookups, 90% lookups and 99% lookups the number of lookups per read is 1, 9 and 99 respectly. There are one to ten updates per transaction.

In each case the median of five results was taken. The intension is to have an application which behaves the same way every time so variation needs to be minimised.

The Linux blade was a 2 CPU dual core Opteron 270 machine with 8 GB of memory and a mirrored UltraSCSI disk.

Each update is written to all four masters before proceeding. This ensures that each update is highly available.

Note: The two master and one master configurations were estimated. In reality, if each master had more than one thread updating more than one collection you could achieve the four master result or even higher. To some degree the four master benchmark tests the performance that server can deliver. Using more servers over a fast network could deliver higher performance.

Modest benchmark results

So the result is that on a fast machine you get fast results. What is the behaviour on a more modest machine?

These tests were performed on a Windows PC with a Pentium D 3.0 GHz.

The most meaningful result is the "99% lookups" benchmark. This gives an indication as the performance you might get under load.

In the "to disk, compressed" test, the directory written to has compression on. The compression ration was about 4 to 1. This is the size for 100,000 entries.

The + 1KB, + 8KB and + 64 KB have a byte[] with this many bytes added to the price object. This simulates the effect of having larger object sizes. In the case of the + 64 KB, you would need a switched Gbit connection to sustain this kind of rate. In the + 1KB, case a switched 100 Mbit should be sufficient to sustain these rates.

Notes

Essence 0.65 and JDK 1.5.0_08 were used in these benchmarks.