Imported from previous forum
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
What are the expected maximum throughputs for FIX engines? By this I mean, for a sell-side institution receiving orders from the buy-side, what sort of volumes can the various engines handle in burst and or / sustained flow?
Does anyone have any experience of handling say 80 orders per second? What sort of hardware is needed for that?
Have any vendors tested this?
Thanks.
John Greenan
[ original email was from Martin Koopman - mk@cameronsystems.com ]
Hi John,
80 orders per second would be no problem for the CameronFIX engine (or I would expect for any of our competitors) running on some pretty basic hardware. Certainly most of our sell-side clients do significantly more than this every day.
Performance figures can be a bit subjective as you would expect. However one of our New York based sell side clients reported these figures using CameronFIX in a production environment running on a dual 1GHz Intel processor machine running under Linux. Recovery persistence was implemented using our standard flat file transaction logs.
Without recovery: 3,350 messages received per second, 4,860 messages sent per second
With recovery: 2,100 messages received per second, 3,100 messages sent per second
Hope this helps.
Regards
Martin
Martin Koopman
Commercial Director
Cameron Systems Pty Ltd
email: mk@cameronsystems.com
ph: 212-858-7701
CameronFIX - Number One In Reputation
http://www.cameronsystems.com
> What are the expected maximum throughputs for FIX engines? By this I mean, for a sell-side institution receiving orders from the buy-side, what sort of volumes can the various engines handle in burst and or / sustained flow?
>
> Does anyone have any experience of handling say 80 orders per second? What sort of hardware is needed for that?
>
> Have any vendors tested this?
>
> Thanks.
>
> John Greenan
>
John,
Martin is correct - any solid fix engine should have no problem handling 80 orders per second.
Many things can affect engine performance, including: poorly-architected software, slow persistence (such as some SQL databases), and
validation/processing logic. When comparing performance numbers between engines, keep these things in mind. Turning off validations or persistence is a convenient (and common) way for a vendor to boost performance numbers. But, benchmarking a messaging engine without persistence or validations is pointless, since this would not be a production configuration.
Our recommended platform for ttCONNECT is a dual 1GHz Intel machine with 512Mb RAM running Linux or WindowsNT (about a $2500 machine). On this platform, using the in-process API, with flat-file persistence and all standard FIX validations, ttCONNECT can process over 3,000 messages per second (sent and received) and can handle hundreds of connections.
Regards,
Will Walter
Professional Services
www.transacttools.net
212-542-8764
> Hi John,
>
> 80 orders per second would be no problem for the CameronFIX engine (or I would expect for any of our competitors) running on some pretty basic hardware. Certainly most of our sell-side clients do significantly more than this every day.
>
> Performance figures can be a bit subjective as you would expect. However one of our New York based sell side clients reported these figures using CameronFIX in a production environment running on a dual 1GHz Intel processor machine running under Linux. Recovery persistence was implemented using our standard flat file transaction logs.
>
> Without recovery: 3,350 messages received per second, 4,860 messages sent per second
> With recovery: 2,100 messages received per second, 3,100 messages sent per second
>
> Hope this helps.
>
> Regards
>
> Martin
>
> Martin Koopman
> Commercial Director
> Cameron Systems Pty Ltd
>
> email: mk@cameronsystems.com
> ph: 212-858-7701
>
> CameronFIX - Number One In Reputation
> http://www.cameronsystems.com
>
>
>
>
> > What are the expected maximum throughputs for FIX engines? By this I mean, for a sell-side institution receiving orders from the buy-side, what sort of volumes can the various engines handle in burst and or / sustained flow?
> >
> > Does anyone have any experience of handling say 80 orders per second? What sort of hardware is needed for that?
> >
> > Have any vendors tested this?
> >
> > Thanks.
> >
> > John Greenan
> >
>
[ original email was from Sam Johnson - sam.johnson@transacttools.net ]
(in response to Maximum Throughput?? by John Greenan)
TransactTools has just completed a round of performance benchmarks for our ttCONNECT messaging engine.
On low-end hardware (a single Dell PC, running Linux, with dual 933 MHz Pentiums – approx $1,700) ttCONNECT can send and receive 8,250 orders per second across up to 64 simultaneous FIX connections, with persistence and with message validations. Scale up to 128 simultaneous connections, and ttCONNECT still does more than 7,000 order per second.
Real-world, production scenario. As far as we can tell, this is the highest throughput of any engine on the market by a good margin.
If you are interested in ttCONNECT and would like to receive a copy of our benchmark and features comparison document, drop us an email at info@transacttools.net
Sam Johnson
TransactTools