Frederic Pariente Engineering Manager at Sun Microsystems posted an interesting summary of a case study with GigaSpaces on Sun blog: Gigaspaces curbs latency outliers with Java Real Time
light of the 2.0 release of Java Real Time System –JRTS 1.0 had the
bad prerequisite of source code changes–, Gigaspaces revisited the
opportunity for Java Real Time to serve the low-latency requirements of
trading applications. Gigaspaces XAP 6.5, Solaris 10 and both Java 5.0
standard and real-time JVMs were used for the benchmark. The test
scenario included a trade matching engine and multiple clients
injecting messages at extreme speed. The success criteria was to get
guaranteed latency per message under 10 msec, with no code modification
to the matching engine"
"..The first lesson learned was that msec latency was achievable with the
standard JVM, through some advanced tuning of the JVM command-line
options. While the customer had reported application freezes up to 20
sec during garbage collection under heavy load –he was running the JVM
with no particular flags, unfortunately default JVM options optimize
for throughput–, latencies could be brought down to milliseconds by
switching to the Concurrent Garbarge Collector"
reduced by an order of magnitude by using the real-time JVM. At a small
cost in terms of application throughput –lower– and CPU usage
–higher– of course"
You can see the full detailed benchmark and JVM option in the original post.
How Real Time JVM works?
For those who are not faimiliare with Real Time JVM, Fredric points to a very detailed presentation on his post Java Real Time for latency-critical banking applications which I’d recommend looking at. I took one slide from the presentation which i found useful for understanding the general concept behind Real Time VM.
As could be seen in the above diagram the RT-JVM introduces new type of threads "Critical RT threads". It makes sure that GC will not run while those thread are running and in that case provide better predictable behavior.