# Maximum Throughput???

**URL:** <https://forum.fixtrading.org/t/maximum-throughput/10048>\
**Category:** General Q&A\
**Tags:** product-discussion, xid\_170250, imported\
**Created:** [May 23, 2002, 3:30pm UTC](https://forum.fixtrading.org/t/maximum-throughput/10048 "2002-05-23T15:30:00Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\
**Post date:** [May 23, 2002, 3:30pm UTC](https://forum.fixtrading.org/t/maximum-throughput/10048/1 "2002-05-23T15:30:00Z")

</div>

Imported from previous forum

---

<div class="post-metadata">

**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\
**Post date:** [May 23, 2002, 3:30pm UTC](https://forum.fixtrading.org/t/maximum-throughput/10048/2 "2002-05-23T15:30:00Z")

</div>

[original email was from John Greenan - [john.greenan@alignment-systems.com](mailto: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

---

<div class="post-metadata">

**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\
**Post date:** [May 23, 2002, 5:29pm UTC](https://forum.fixtrading.org/t/maximum-throughput/10048/3 "2002-05-23T17:29:00Z")

</div>

[original email was from Martin Koopman - [mk@cameronsystems.com](mailto: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](mailto:mk@cameronsystems.com)  
ph: 212-858-7701

CameronFIX - Number One In Reputation  
[http://www.cameronsystems.com](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  
\>

---

<div class="post-metadata">

**Author:** ![willwalter\_x](https://avatars.discourse-cdn.com/v4/letter/w/9de053/32.png) [@willwalter\_x](https://forum.fixtrading.org/u/willwalter_x)\
**Post date:** [May 24, 2002, 3:28pm UTC](https://forum.fixtrading.org/t/maximum-throughput/10048/4 "2002-05-24T15:28:00Z")

</div>

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](http://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](mailto:mk@cameronsystems.com)  
\> ph: 212-858-7701  
\>  
\> CameronFIX - Number One In Reputation  
\> [http://www.cameronsystems.com](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  
\> \>  
\>

---

<div class="post-metadata">

**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\
**Post date:** [June 22, 2002, 7:50pm UTC](https://forum.fixtrading.org/t/maximum-throughput/10048/5 "2002-06-22T19:50:00Z")

</div>

[original email was from Sam Johnson - [sam.johnson@transacttools.net](mailto: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](mailto:info@transacttools.net)

Sam Johnson  
TransactTools
