How Asynchronous Logging Affects QuickFIX Performance

Summary

The discussion explains that logging adds computational work to QuickFIX and that writing log records to disk can add substantial latency. Disabling file logging may improve performance, but the answers suggest keeping logging while reducing its impact on the message-processing path. Proposed approaches include increasing buffers and handing log messages to a separate thread or core through middleware or an asynchronous logging framework. The discussion also mentions the disruptor pattern as a way to pass messages between threads.

The evidence is qualitative: contributors describe the cost of logging and disk I/O, without benchmarking QuickFIX configurations directly. One answer cites throughput and latency figures for a separate logging product, but its author discloses being a developer of that product, so those figures should not be treated as independent evidence. The thread does not compare implementation choices, quantify tradeoffs, or explain how asynchronous logging affects durability and message loss. The practical lesson is that logging can burden a latency-sensitive trading path, while buffering and off-thread processing may help; the best choice depends on the system and its logging requirements.

Key ideas

• Logging consumes compute resources and file writes can add latency to QuickFIX processing.
• Disabling file logging may reduce overhead, though the discussion offers no direct benchmark.
• Larger buffers and asynchronous logging can move some work away from the main processing path.
• The cited performance figures concern a separate logging product and come from one of its developers.
• Logging design involves tradeoffs that the discussion does not quantify, including durability and latency.

Tags

# How does logging effect Quickfix performance?


# How does logging effect Quickfix performance?












I am using .net/c++ version of quickfix. How does logging effect Quickfix performance? If I disable logging to file, can it help to increase performance of quickfix?

Thanks,

## Answer by chollida (score 1)

https://quant.stackexchange.com/a/11553

I answered a stackoverflow question that was pretty much identical over here

Maybe it was you who cross posted. Long story short, logging has a real cost. Sadly there isn't alot you can do to get around it with a stock quickfix implementation.

## Answer by madilyn (score 1)

https://quant.stackexchange.com/a/12929

Same answer as @chollida - any kind of logging has real computational cost. You can improve on the QuickFIX implementation without disabling the logging functionality by increasing the buffer size, or using message middleware to pass the logging task to another thread or core (which therefore amortizes the total computation time in the QuickFIX path).

## Answer by rdalmeida (score 1)

https://quant.stackexchange.com/a/14393

Disk I/O has a big latency cost, so you must use an asynchronous logging framework and the fastest way to pass messages from thread A to thread B is to use the disruptor pattern. For a good event sourcing (i.e. logging to a file without log levels like info, warn, error, etc.) framework you can take a look on CoralLog. It can log a 64-byte message in 87 nanoseconds on average. When it comes to throughput it can easily log 4 million 64-byte messages per second. That should be more than enough for most HFT strategies.

Disclaimer: I am one of the developers of CoralLog.

Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.