Imported from previous forum
Performance is based on a number of factors including…
-
The speed of FIX engine(s) and system(s) in which the buyer and seller
systems operate:
There are a variety of FIX engines available, some fast others not so fast.
These may require fast machines in order to achieve the best performance.
A well designed system will not be CPU bound on the buyers side. A sell side
system serving many connections can get quite loaded if there is no load
balancing utilized. -
Speed of order matching system
Once a FIX order has been received on the sell side through the FIX stack it
has to be matched. The message must be delivered to the application layer
and a execution report, reject, etc must be returned. In a 4.2 secure
channel, some work will need to be performed to encrypt/decrypt the contents
of the message. -
Speed of network link from buyer to seller
This will dictate the maximum order rate.
What are typical numbers…?
In my experience a direct connected FIX client / server where the client
places an order and the server issues a complete fill for every order
placed, total orders per second ( order->, <-execution report) can range
anywhere from 200-2000 / second based on the FIX code, systems and network
being used. Yes this is a wide range. If you want speed, get a fast box and
a fast implementation. But, don’t compromise the reliability of FIX in the
processes.
-peter
Peter Mellquist
Watcher Technolgies
----- Original Message -----
From: "The FIX Protocol Organization" <updates@fixprotocol.org>
To: <pmellquist@watchertech.com>
Sent: Tuesday, March 13, 2001 6:28 PM
Subject: General Q/A : re: performance
> Regarding the performance of FIX:
> how many standard orders can be sent secure in a minute using the FIX
protocol?
>
>
> --------------
> Alexander Parisini
> ABS
> abs@abs-cm.ch
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
This post raised some very good points on the subject of performance. Some other thoughts on this subject:
Throughput and latency are not interchangeable, and latency often isn’t often that great a benchmark of performance.
One system may have a constant 50 ms latency, but can only process 20 orders a second. Another may have 500 ms latency, but that latency is constant regardless of whether you’re doing 1 order per second, or 500 orders per second. Another may have 50 ms latency at 1 order per second, but have 500 ms latency at 10 orders per second, and start getting farther and farther behind at 20 orders per second. How does the system handle bursts vs. sustained order rates?
As was stated, reliability can affect performance. In general, adding more reliability will generally increase latency, and can possibly throttle throughput. And reliability comes in many flavors. Does a FIX engine do nothing about reliability? Does it have a lazy thread writing behind, such that you may lose a second or two of trading should something crash and have to be restarted? Are things committed to a local disk, which is often faster but vulnerable to that one computer failing, or committed to other computers / database servers which can increase latency? Do you wait for successfully committing data before talking to the client, or do you tell the client concurrently with committing the transaction, thus allowing for in-flight transactions to be lost should the system crash? Is data committed to a disaster recovery site, and how much data, if any, would be lost if one had to roll over to that site? All of these decisions can have serious performance implications.
Further, there’s the difference between acks and trades. A lot of people have a mistaken notion that order ack time is the be-all-end-all of benchmarks when evaluating ECNs/Exchanges, which I find very shortsighted. It is extremely one-dimensional; it does not address maximum sustained or bursting throughput at all, or how the latency changes as a function of orders per second. It penalizes reliability. And an order ack doesn’t even necessarily mean the same thing to different systems. ECNs/Exchanges may ack an order right on the FIX front end, or they may carry the order all the way into their system and ack it only when it hits the book. The former may give faster ack times, but it hides bottlenecks internal to the ECN from the client, while the latter exposes them. I think a more viable benchmark is how fast it takes an ECN to fill an order that internally crosses another order, and even that only makes sense when one adds in the dimension of how that varies with regard to throughput. Which is better? An ECN that can ack an order in 50 ms and fill it in 1000 ms, or one that can ack an order in 500 ms and fill it 50 ms later?
As stated, networks can affect performance as well. The bandwidth involved in FIX is generally not that much, so that one can generally scale the network pipe to be sufficiently more than the maximum sustainable throughput one requires, however latency often can be greatly affected by the network. You may get one set of benchmarks connecting to a system on your local host or across 100BaseT Ethernet. You may get different results on a 56k frame relay circuit, or over the Internet.