[QFJ-509] Question about performance Created: 24/Feb/10  Updated: 20/Mar/11  Resolved: 20/Mar/11

Status: Closed
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.4.0
Fix Version/s: None

Type: Other Priority: Critical
Reporter: Ilya Goberman Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows XP 32 bit, Java 6.



 Description   

I wrote a FIX server that streams market data to FIX subscribers. The market data volume may be heavy, so I need to find out performance benchmarks for QuickFixJ API.
I have a test set up where Server is running on 4 core XP machine streaming FIX market data messages to a subscriber running on another machine. I do not use any file IO because I do not use FileStoreFactory/FileLogFactory - so no files are created in my logs directory for both server and subscriber.
The server just sends market data messages in infinite loop without any delays. The message is MarketDataIncrementalRefresh with Bid and Offer groups containing Bid, Ask, BidSize, and AskSize - 4 fields.

Now the problem is that I cannot receive over 12,000 messages per second. My CPU is not maxed out on client or server. It is interesting that if I add another thread on the server also sending the same messages in a loop, the number of processed messages does not increase.

My question is: is it possible to process over 12,000 in configuration described above or this number "is about correct". Is there way to improve it somehow (I already eliminated file IO)? My guess there is some thread contention going on in the QuickFixJ API that prevents achieving good throughput.
Thanks



 Comments   
Comment by Steve Bate [ 05/Apr/10 ]

Are you using a single session? In any case, given that you probably aren't doing two-way communication, thread contention /shouldn't/ be the primary issue. However, if you see otherwise in your profiling please let us know. Other possibilities are garbage collection (especially if the heap size is set too low) and network bottlenecks.

Generated at Tue Jul 01 07:36:37 UTC 2025 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.