By Frederic Pariente on Dec 19, 2008
"Latency matters. Amazon found every 100ms of latency cost them 1% in sales. Google found an extra .5 seconds in search page generation time dropped traffic by 20%. A broker could lose $4 million in revenues per millisecond if their electronic trading platform is 5 milliseconds behind the competition."
Latency is Everywhere (...), High Scalability Blog, Todd Hoff
Sun customers can turn to Gigaspaces to hide the network latencies and dramatically increase the performance of their multi-tier applications. Since the release of Java Real Time System (JRTS) 2.0, Gigaspaces customers can now turn back to Sun to further decrease the application latency of their business-critical transactions. Today's proofpoint is covering some engineering work at Gigaspaces this year around JRTS 2.0 to meet the stringent needs of our Financial Services customers with respect to market transaction latencies.
Today, most banks have migrated their internal software development from C/C++ to the Java language because of well-known advantages in development productivity (Java Platform), robustness & reliability (Garbage Collector) and platform independence (Java Bytecode). They may even have gotten better throughput performance through the use of standard architectures and application servers (Java Enterprise Edition). Among the few banking applications that have not been able to benefit yet from the Java revolution, you find the latency-critical applications connected to the trading floor. Why? Because of the unpredictable pauses introduced by the garbage collector which result in significant jitter (variance of execution time).
"If you've got some trades going through at 10 milliseconds and some at 1 millisecond, that's a problem. Our customers don't like variance."
Steve Rubinow, CTO, NYSE
In the context of a customer proof-of-concept this summer and in the 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…[Read More]