How can I track down sources of latency when using the FIX input and output adapters?
Article ID: KB0074907
Updated On:
| Products | Versions |
|---|---|
| TIBCO Streaming | 7 |
Description
In production we are noticing the FIX arrival time and the SendingTime (both in the FIX logs) tend to peak over 100ms. This varies from time to time and there are no large GCs times to indicate Java JVM garbage collection is the cause.
Resolution
To help track down sources of latency when using the FIX adapters, run the FIX latency and throughput tests provided on the StreamBase Component Exchange to independently verify the behavior of the FIX adapters on your network.
Please see:
These are available within Studio using the menu: File > StreamBase Component Exchange
The behaviors to look for are:
a) If the FIX adapter thread hits 100% of a core, there will be backlog.
b) If the latency from the benchmark includes the same peaks, then it is likely not the downstream application causing the problem.
c) If the throughput needed for your business exceeds the throughput shown by the throughput test, then there will be additional queuing and latency.
1. Does each FIX adapter create its own FIX engine instance?
Every FIX adapter instantiates a new FIX engine, but linked input/output pairs instantiate only one.
2. Are FIX messages written to the log before they are handed to the SB application code?
The engine is responsible for maintaining its own logs as referenced in the fix configuration file.
3. If there is a slow downstream application, will this cause the FIX messages to queue and lead to peaks in latency?
The FIX engine has an internal queue that is maintained by its own thread and there is a thread-hop to the StreamBase adapter layer. If the downstream application is occasionally slow, messages will queue at the thread-hop. Queuing adds latency to the queued messages. Well functioning queues typically contain 0 or 1 messages.
4. Is QuickFIX/J a native or pure Java FIX implementation?
QuickFIX/J is a pure-Java implementation.
Please see:
- FIX Message Latency Benchmark Application
- FIX Message Throughput Benchmark Application
These are available within Studio using the menu: File > StreamBase Component Exchange
The behaviors to look for are:
a) If the FIX adapter thread hits 100% of a core, there will be backlog.
b) If the latency from the benchmark includes the same peaks, then it is likely not the downstream application causing the problem.
c) If the throughput needed for your business exceeds the throughput shown by the throughput test, then there will be additional queuing and latency.
FAQ
1. Does each FIX adapter create its own FIX engine instance?
Every FIX adapter instantiates a new FIX engine, but linked input/output pairs instantiate only one.
2. Are FIX messages written to the log before they are handed to the SB application code?
The engine is responsible for maintaining its own logs as referenced in the fix configuration file.
3. If there is a slow downstream application, will this cause the FIX messages to queue and lead to peaks in latency?
The FIX engine has an internal queue that is maintained by its own thread and there is a thread-hop to the StreamBase adapter layer. If the downstream application is occasionally slow, messages will queue at the thread-hop. Queuing adds latency to the queued messages. Well functioning queues typically contain 0 or 1 messages.
4. Is QuickFIX/J a native or pure Java FIX implementation?
QuickFIX/J is a pure-Java implementation.
Issue/Introduction
How can I track down sources of latency when using the FIX input and output adapters?
Feedback
Yes
No
Powered by
