I'm building an arbitrage system, so responding to FIX messages quickly is
essential. I don't need to process hundreds of messages a second, but I
need to respond to the messages that arrive very quickly.
I wrote a simple Initiator client that just logs in. Once Logon is
complete, I change the client's heartbeat interval to be very long, so the
client quits sending HeartBeats. Therefore the server will send a
TestRequest every few seconds, and QuickFix will respond with a heartbeat.
I'm interested in the turnaround time to do that message processing. I used
Wireshark to capture the network traffic so I could see how long it takes
the client to respond.
To make the times as fast as possible, I've done the following:
+ The Log level is WARN, so nothing is being logged
+ Using the MemoryStore for messages
+ UseDataDictionary, ValidateFieldsHaveValues, CheckCompID and CheckLatency
are all turned off
+ SocketTcpNoDelay is turned on
I did this for QuickFix, QuickFix/JNI, QuickFix from C# and QuickFix/J. I
was pleased with how easy it was to get this test running using the various
flavors of QuickFix. The average time to respond in MICROseconds is as
follows:
QuickFix: 235
QuickFix/JNI: 550
QuickFix/C#: 483
QuickFix/J: 501
I don't think the JVI vs .NET vs QuickFixJ differences are significant, but
the C++ times are significantly faster than anything else. For the two Java
apps, I spent some time tuning the JVM's params; I also tried the JRockit
JVM.
My question for the group: Is there an architectural reason why QuickFix
outperforms QuickFix/J? Or is this a case of C++ being faster than Java in
this problem domain (network programming and byte manipulation)?
Thanks,
Ted
|
