paul.nowak wrote: Matt, thanks for the comments. I made an error on the version of Plone. It's 2.5 Plone running on Zope 2.9x.
In regards to the additional products, we have a skin installed and we have a product that we had custom developed for us that connects to a PostgreSQL database. We've looked at slow PostgreSQL queries causing problems and have not been able to find an issue. We've also tested for the case where the PostgreSQL server is down and have not been able to create an issue. We therefor...
Front office financial applications that place and execute orders are different from many others, since real-time trading systems must be blazingly fast and reliable. A few seconds delay may cost a financial brokerage company millions of dollars and potential penalties.
If, back in the '90s, you'd suggested using Java for processing split-second stock market orders, most of the New York programmers would just simply say: "faggedaboudid." If you want to have some fun, read old articles on using Java for Wall Street applications. Here are some statements made a long time ago in 1997:
Java is strong on the front end, but we do not foresee it being used for very large number-crunching applications.
Java is fine only for very thin clients.
A couple of years ago I was participating in the design and development of a multitier and multiplatform equities trading system that was built around Java Messaging and Enterprise JavaBeans (both session and entity beans). This real-time system has successfully replaced a legacy C++ application, has been deployed in production, and worked happily ever after. Not only was it more stable than the legacy system, but it was a lot more scalable. Multithreaded listeners retrieve orders from one or more message queues and send them to a cluster of J2EE application servers. Need more processing power? Just add another application server to the cluster, add more queues, and purchase additional communication lines with the stock exchange. No code changes required.
This Fall I attended the conference "High Performance Technology on Wall Street" and if I had to describe this event in only one word, I'd use the word "grid." If I was allowed to add a second word, this would be "blades," and the third one would be "Java."
Software vendors have casually talked about using various Java technologies in high-speed real-time applications. Most of the vendors were either presenting software or hardware for grid computing. Blade servers are also becoming popular. Blades have nothing to do with shaving. Just imagine a metal cabinet with multiple narrow slots. Each slot hosts a blade server, which is a board with two or four processors, memory, and a local hard drive. All blades share high-speed I/O switches for communication with the rest of the world. Grid servers and agents are the software that supports such parallel computing.
Speakers presented colorful diagrams with hundreds of parallel jobs running on a grid; if one of the servers fails, the job gets redirected to another blade. Nice! But let's look at this technology from a practical point of view. Proprietary computation-centric, financial analytic software can be more or less easily divided into a set of parallel Java jobs. But how about running a hundred parallel application servers? This is also possible...if you have the budget to purchase hundreds of licenses for production, contingency, and QA environments. Most likely, these hundreds of servers will need to access either some data warehouse or a transactional database. If your system can't move the data fast enough between your application servers and the database, I/O may become a bottleneck of such a system. It's like driving a Ferrari on local streets.
I like this powerful technology and encourage you to present it as an option to your users. Can you process terabytes of data? Yes! Can you double the throughput? Sure! Technology is available...as long as you guys can afford it.
Another interesting topic was using XML for real-time systems. We already got used to application servers, database servers, Web servers, directory servers, intelligent business servers...please welcome: XML Server Farm. These agricultural machines are responsible for parallel XML parsing. If a system needs to send an order to a stock exchange to buy a hundred shares of SUN, we try to minimize the number of bytes that have to be processed, and "SUN,100" looks more attractive than "<Symbol>SUN</Symbol><Quantity>100</Quantity>". Who knows, maybe a couple of years from now the "slow XML" will be as funny as a "slow Java" is today.
Java feels at home in middle and back office applications that calculate risk and perform financial modeling utilizing functions for nonlinear optimization, statistical analysis, time-series analysis, and others. Some applications analyze trades that have already happened. As the brokerage industry introduces more and more regulations, financial giants are being fined heavily for cutting corners and breaking the rules. Applications that can process enormous amounts of data and weed out violations receive prime funding. Even though these Java applications may not need to process orders in real time, they also need a lot of power to sift the terabytes of data through various rule engines. These business intelligence servers use such in-memory gadgets as embedded Java databases, asynchronous nonpersistent queues, data caching, and parallel processing. Have I mentioned grids and blades yet?
Some heavy-duty Java gurus try to stay away from business applications, believing that the real fun coding is in companies that develop compilers, browsers, search engines, application servers, and the like. Trust me, these IT guys on Wall Street are not counting crows either. What's even more important for real geeks, you can work for a solid financial company and have as many earrings as you'd like, a long ponytail, grow a beard, and wear T-shirts and jeans. Wall Street welcomes the James Gosling look and feel!
About Yakov Fain Yakov Fain is a Managing Director of Farata Systems, consulting, training and product company. He has authored several Java books, dozens of technical articles. SYS-CON Books released his latest co-authored book , Rich Internet Applications with Adobe Flex and Java: Secrets of the Masters in Spring 2007. Sun Microsystems has nominated and awarded Yakov with the title Java Champion. He leads the Princeton Java Users Group. He is an Adobe Certified Flex Instructor. Currently Yakov works on the book for O'Reilly "Enterprise Application Development with Flex". He twits at twitter.com/yfain.
>Which ECN is the fastest for high volume transactions (say over 2000/sec) ?
I do not have the exact numbers, but Island Electronic Communication Network is probably one of the best ECNs (they claim more than 10000 messages per second). What's more important that they have scalable architecture built on thousands of servers.
>So, is Java preferred to C for executing trades ?
I do not want to open this can of worms again J Here's a short answer: If you'll benchmarks C and Java language elements, C is faster. But in Java you can build a schalable application using multithreading, messaging, app servers that will beat C hands down. You can say that you can do the same using C, but it'll cost you many times more than in Java.
>Can Java 1.42 handle this or is Java 1.5 the solution ?
We did it using Java 1.3 and Java 1.5 would make it faster without changing even one line of code. Just start your servers using Java 5.0 JVM.
>Unix and C have issues with memory maps and persistance to disk. Unix Shared memory may be faster. Java has the infamous JVM and Garbage collections, but if properly tuned and with multiple Matching Engines, thus multiple JVMs, can Java be faster than C ?
Java has its issues, but again, properly designed J2EE applications can be blazing fast
>How about the Java based Berkeley DB (from SleepyCat Software) that
resides in the JVM ? Is such a solution Java's answer to Unix Shared memory for speed ?
We used a small J2EE vendor that added so called pinned-to-cache feature that would allow keep entity beans in memory minimizing the number of database requests. For example, if you need to find an OrderBean, it may be found in memory. I'm sure Berkley DB may have its advantages over persisted DBMS, but I'd also consider using non-persistent messages that are stored in memory.
Regards,
Yakov
#6
Ted Hruzd commented on 3 Apr 2005
Yakov:
I like your Nov 2004 JDJ article regarding "Java on Wall Street", especially a summary regarding how Java applications for brokerage trading can scale.
How about the Matching Engine side - to quickly receive, store, match buy/sell orders, and ultimately trade orders ? I hear that Instinet uses a Java Matching Engine (maybe multiple ones ... to scale), and that ArcaX runs Matching Engines with Solaris / C, and that Nasdaq SuperMonTage is an HP ( Tandem NonStop ) multiple Server solution. Nasdaq purchased Brut recently.
Brut is a Solaris shop but I am unsure whether its Matching Engine is C or Java. Which ECN is the fastest for high volume transactions (say over 2000/sec) ?
So, is Java preferred to C for executing trades ? Can Java 1.42 handle this or is Java 1.5 the solution ? Unix and C have issues with memory maps and persistance to disk. Unix Shared memory may be faster. Java has the infamous JVM and Garbage collections, but if properly tuned and with multiple Matching Engines, thus multiple JVMs, can Java be faster than C ?
How about the Java based Berkeley DB (from SleepyCat Software) that resides in the JVM ? Is such a solution Java's answer to Unix Shared memory for speed ?
I enjoy reading all of your articles and would greatly apprecaite your perspective. I have been a Java Programmer, then Performance Engineer over the past 10 years.
regards,
Ted Hruzd
#5
sleepingbear commented on 22 Nov 2004
<"slow XML" will be as funny as a "slow Java" is today.> -- back when everything was a lot slower, electronic data interchange standards groups went to a lot of effort to minimize bytes transferred and interpreted. "SUN,100" can be compressed a lot more. But it is not self-defining nor human readable then -- one of the motivators for XML. OTOH, not many people I know actually read or write XML much.
#4
Vlad commented on 17 Nov 2004
Hi, Yakov:
Unfortunately, not ALL Financial Companies welcome "James Gosling Look-n-Feel".
Nice article.
#3
df commented on 17 Nov 2004
>> the C/C++ will always run faster than Java kind..
for last 1-2 years it is not true anymore
you can find lot of benchmarks, where the speed is similiar or even little bit faster for JAVA
e.g. C++ segmentation of the heap memory can be a performance problem, which is solved by the JAVA GC
#2
GeekInTheCity commented on 16 Nov 2004
I was a sceptic... the C/C++ will always run faster than Java kind... the requirements kept coming in so fast that I didn't have time to write it in C++ and now our Order Management System is 100% Java...
#1
Andrey Postoyanets commented on 16 Nov 2004
Awesome article! Thanks Yakov!
It's always sad to hear that "Java is slow/not applicable for real-time apps" from people who tried Java 3-5 years ago and it did not work out for them; Yakov is referring to the trading system application that was developed during the same time! Java itself has become more mature since then and many products (profilers, optimizers, test tools etc.) were developed/enhanced. All of this helps to meet performance objectives and ensure hardware scalability versus software rewrite, if proper system architecture solutions are applied. You just have to keep your knowledge up-to-date and love the work you do.
Yakov Fain wrote: >Which ECN is the fastest for high volume transactions (say over 2000/sec) ?
I do not have the exact numbers, but Island Electronic Communication Network is probably one of the best ECNs (they claim more than 10000 messages per second). What's more important that they have scalable architecture built on thousands of servers.
>So, is Java preferred to C for executing trades ?
I do not want to open this can of worms again J Here's a short answer: If you'll benchmarks C and Java language elements, C is faster. But in Java you can build a schalable application using multithreading, messaging, app servers that will beat C hands down. You can say that you can do the same using C, but it'll cost you many times more than in Java.
>Can Java 1.42 handle this or is Java 1.5 the solution ?
We did it using Java 1.3 and Java 1.5 would make it faster without changing even one line of code...
Ted Hruzd wrote: Yakov:
I like your Nov 2004 JDJ article regarding "Java on Wall Street", especially a summary regarding how Java applications for brokerage trading can scale.
How about the Matching Engine side - to quickly receive, store, match buy/sell orders, and ultimately trade orders ? I hear that Instinet uses a Java Matching Engine (maybe multiple ones ... to scale), and that ArcaX runs Matching Engines with Solaris / C, and that Nasdaq SuperMonTage is an HP ( Tandem NonStop ) multiple Server solution. Nasdaq purchased Brut recently.
Brut is a Solaris shop but I am unsure whether its Matching Engine is C or Java. Which ECN is the fastest for high volume transactions (say over 2000/sec) ?
So, is Java preferred to C for executing trades ? Can Java 1.42 handle this or is Java 1.5 the solution ? Unix and C have issues with memory maps and persistance to disk. Unix Shared memory may...
sleepingbear wrote: <"slow XML" will be as funny as a "slow Java" is today.> -- back when everything was a lot slower, electronic data interchange standards groups went to a lot of effort to minimize bytes transferred and interpreted. "SUN,100" can be compressed a lot more. But it is not self-defining nor human readable then -- one of the motivators for XML. OTOH, not many people I know actually read or write XML much.
df wrote: >> the C/C++ will always run faster than Java kind..
for last 1-2 years it is not true anymore
you can find lot of benchmarks, where the speed is similiar or even little bit faster for JAVA
e.g. C++ segmentation of the heap memory can be a performance problem, which is solved by the JAVA GC
GeekInTheCity wrote: I was a sceptic... the C/C++ will always run faster than Java kind... the requirements kept coming in so fast that I didn't have time to write it in C++ and now our Order Management System is 100% Java...
Andrey Postoyanets wrote: Awesome article! Thanks Yakov!
It's always sad to hear that "Java is slow/not applicable for real-time apps" from people who tried Java 3-5 years ago and it did not work out for them; Yakov is referring to the trading system application that was developed during the same time! Java itself has become more mature since then and many products (profilers, optimizers, test tools etc.) were developed/enhanced. All of this helps to meet performance objectives and ensure hardware scalability versus software rewrite, if proper system architecture solutions are applied. You just have to keep your knowledge up-to-date and love the work you do.
This is a deal that has been around for all of this year, and I know the NYC-based guy charged with pulling the technical pieces together. He has been looking at software platforms for months and separating contenders from pretenders based on the criteria he's established. To my knowle...
3Leaf Systems, the well-funded start-up, dropped its fig leaf Tuesday and took a running jump into the pools of memory, I/O and cache that it can construct and deconstruct at will based on the application, creating scale-up shared-memory SMP systems the likes of mainframes, proprietary...
Funambol, a provider of open source mobile cloud sync and push email for billions of phones, today announced it has acquired Zapatec, Inc., a leader of AJAX web 2.0 frameworks. The acquisition enables Funambol to uniquely address the industry pervasive device fragmentation challenge th...
Plone and Drupal are two leading open source Content Management Systems (CMS). Both were recognized in the 2009 Open Source CMS awards, run by Packt Publishing. Both also have large installed bases and large developer communities. This is made evident by some quick searching on Googl...
SOASTA, a provider cloud testing, today announced that performance engineers can now build web application tests in Apache JMeter, the most popular open source load testing tool, and run them in SOASTA's Global Test Cloud. Deploying JMeter tests to the Cloud has been a complex, time-co...
Yahoo! Inc. (Nasdaq:YHOO), a leading global Internet company, took its second major step in five months towards open-source cloud computing today, debuting an open source version of Traffic Server, a high performance application server for builders of cloud services. Traffic Server ena...
.gif)
This is a deal that has been around for all of this year, and I know the NYC-based guy charged with pulling the technical pieces together. He has been looking at software platforms for months and separating contenders from pretenders based on the criteria he's established. To my knowle...
3Leaf Systems, the well-funded start-up, dropped its fig leaf Tuesday and took a running jump into the pools of memory, I/O and cache that it can construct and deconstruct at will based on the application, creating scale-up shared-memory SMP systems the likes of mainframes, proprietary...
Funambol, a provider of open source mobile cloud sync and push email for billions of phones, today announced it has acquired Zapatec, Inc., a leader of AJAX web 2.0 frameworks. The acquisition enables Funambol to uniquely address the industry pervasive device fragmentation challenge th...
Plone and Drupal are two leading open source Content Management Systems (CMS). Both were recognized in the 2009 Open Source CMS awards, run by Packt Publishing. Both also have large installed bases and large developer communities. This is made evident by some quick searching on Googl...
SOASTA, a provider cloud testing, today announced that performance engineers can now build web application tests in Apache JMeter, the most popular open source load testing tool, and run them in SOASTA's Global Test Cloud. Deploying JMeter tests to the Cloud has been a complex, time-co...
Yahoo! Inc. (Nasdaq:YHOO), a leading global Internet company, took its second major step in five months towards open-source cloud computing today, debuting an open source version of Traffic Server, a high performance application server for builders of cloud services. Traffic Server ena...
