[Quickfix-developers] Quickfix/J - Production Use Report
Brought to you by:
orenmnero
|
From: Barry K. <bk...@bl...> - 2005-07-21 17:48:28
|
It was mentioned in the beta release announcment that I was using QFJ in a production trading application. I will here describe that application and our experiences with QFJ. The application is a blackbox system, running an arbitrage strategy. The strategy will place limit orders on any number of instruments. There will always be an order at the market, but there are often orders a few price tiers down as well. Both long and short orders are placed for an instrument. Opening orders are placed on one exchange, closing orders on another. The system is designed to run against hundreds of instruments concurrently, but so far our we have not exceeded six. The opening orders are entered at some criteria and cancled at another criteria. In a typical trading dary, for a single instrument we will place and cancel several thousand orders, get ten to fifty fills with a corresponding number of closing orders and their fills. When the market is moving, we have seen the placing and canceling of orders peak at 10/sec. The CPU on the 1.8GHz Intel Suse box remaining less than 20% during these peaks. While we have not yet done any detailed performance measurements (ie, YourKIT/JProfiler style), we track the time it takes for us to process market events and send/cancel order and the time it takes to send a closing order on receipt of a fill. For the case when we receive a fill and place the closing order, the time in our system averages 10 millseconds. This time includes: - processing of the fix message by quickfix - internally dispatching the message via jms (using ActiveMQ) - pushing the message thru a rete rule base (using Drools) - sending the closing order via quickfix In some quickfix specific load testing we performed (and this was before some of Steve's performance improvements), we were able to push 10k msgs/sec from on instance of QFJ ot another on the same box. So my guess is that QFJ contribution to that 10ms time is very small. So far, in all our production runs we have not had a single QFJ problem. The system has worked perfectly. I will point out however, that we are using very basic FIX capabilties. Standard 4.2, only new-orders, execution-report, and cancel-order. Also we are using the MemoryStore because we always close all positions prior to shutting down. But we will in any case change to the SleepyCatStore soon. So should you be considering the move to QFJ, I would not hestitate to begin testing. And as Steve mentioned there are some other goodies on the way. In addition to the JMX support, I have been working on complete Spring integration (the application above is Spring based), the conversion of the Netty socket layer to the Mina, and a JMS transport protocol. More to come on this in future betas. If anybody has further questions about our use of QFJ, or the new features, feel free to email me, or better, post here on the list! --- Barry Kaplan bk...@bl... |