Quickfix/J - Production Use Report

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Quickfix/J - Production Use Report

Barry Kaplan-3
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

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
[hidden email]



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Quickfix-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-developers
Reply | Threaded
Open this post in threaded view
|

Re: Quickfix/J - Production Use Report

Alvin Wang

Hi Barry,

Have you got chance to compare the performance of Quickfix/J with that of Quickfix Java/JNI on your application?

thanks
Alvin




Barry Kaplan <[hidden email]>
Sent by: [hidden email]

07/21/2005 01:48 PM

       
        To:        quickfix <[hidden email]>
        cc:        
        bcc:        
        Subject:        [Quickfix-developers] Quickfix/J - Production Use Report



QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

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
[hidden email]



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Quickfix-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


********************************************************************** This e-mail message is intended solely for the use of the addressee. The message may contain information that is privileged and confidential. Disclosure to anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message. We have taken precautions to minimize the risk of transmitting software viruses but nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by software viruses. **********************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Quickfix/J - Production Use Report

Barry Kaplan-3
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ QuickFIX Support: http://www.quickfixengine.org/services.html Alvin Wang wrote:
Have you got chance to compare the performance of Quickfix/J with that of Quickfix Java/JNI on your application?
No Alvin. I have never used the JNI version. Wouldn't be able to either as our system uses spring to configure quickfix. But I believe Steve has done preliminary comparisons against JNI, and the pure Java is much faster as expected.

-- 
barry kaplan
[hidden email] ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Quickfix-developers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quickfix-developers
Reply | Threaded
Open this post in threaded view
|

Re: Quickfix/J - Production Use Report

Bugzilla from Joerg.Thoennes@macd.com
QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
QuickFIX Support: http://www.quickfixengine.org/services.html

Barry Kaplan wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ QuickFIX Support:
> http://www.quickfixengine.org/services.html Alvin Wang wrote:
>
>> Have you got chance to compare the performance of Quickfix/J with that of
>> Quickfix Java/JNI on your application?
>
> No Alvin. I have never used the JNI version. Wouldn't be able to either as our
> system uses spring to configure quickfix. But I believe Steve has done
> preliminary comparisons against JNI, and the pure Java is much faster as expected.

In this context, a comparison of pure Java and pure C++ would be interesting, too.

Cheers, Jörg

--
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Quickfix-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-developers