通过quickfixj发送时如何更快地处理修复消息
我在 QuickfixJ 中遇到处理速度问题。我在这个问题中读到它是可能的每秒处理 300 条消息。我还看到其他地方报道的数字有数千。我的Quickfix会话代码接收消息列表并通过Session.SendToTarget()将它们一一发送；
我发送消息的循环可能会减慢我的速度，但我想知道是否有一种方法可以发送消息列表或加快发送这些消息的过程。也可能是因为我正在登录屏幕，这减慢了我的速度。我会从无头运行并仅记录到文件日志中受益吗？
I am having a problem with processing speed in QuickfixJ. I read in this question that its possible to process 300messages/sec. I also saw elsewhere numbers reported in the thousands. My Quickfix session code receives a list of messages and sends them one by one through Sesssion.SendToTarget();
It is possible that the loop in which I send the messages is slowing me down, but I was wondering is there a way to send a list of message or to speed up the process of sending these messages. It may also be possible that because I am logging to the screen that this is slowing me down. Would I benefit from running it headless and logging to just a file log?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我见过 QuickFIX/J 每秒处理数千条消息。但是，您将很难在单个 FIX 会话中获得该性能。我描述的场景涉及多个会话。这很重要的原因是，由于 FIX 序列号，FIX 协议本质上是按会话顺序进行的。这实际上意味着如果您有一个会话，您就有一个线程处理消息。通过多个会话，引擎可以利用多个线程和处理器。
一般来说，文件 I/O 是主要开销。寻找优化文件系统访问的方法。如果您在没有日志记录和 MemoryStore 的情况下运行引擎，您会发现它非常快。我不会将它用于极低延迟的应用程序，但它也不错。
I've seen QuickFIX/J processing messages in the thousands per second. However, you will have trouble getting that peformance in a single FIX session. The scenario I'm describing involved multiple sessions. The reason this is signficant is that the FIX protocol is inherently sequential per session due to the FIX sequence numbers. This effectively means you have one thread processing messages if you have one session. With multiple sessions, the engine can take advantage of multiple threads and processors.
Generally speaking, file I/O is the primary overhead. Look for ways to optimize the file system access. If you run the engine with no logging and a MemoryStore you'll see it is quite fast. I wouldn't use it for extreme low latency applications but it's not bad.
登录到屏幕会大大降低您的速度。在屏幕上登录时，我每秒会生成 30-40 条消息，如果不登录，我会生成超过 400 条消息。如此简单，不在屏幕上显示任何内容。
另外，这个过程中最慢的部分是来自接受者的答复。发起者设法每秒发送超过 2000 条消息，但接受者的响应减慢了整个过程。
Loging to the screen slow you down very much. With loging on the screen i was making like 30-40 messages per sec and whitout loging i`m making over 400. So simple do not display anything on the screen.
Also the slow part in the process is the answer from the Acceptor. The Initiator manage to send more then 2000 messages per second but the respond of the Acceptor is slowing down the overall process.
您是否在循环中创建每条消息，因为这可能是您的开销？这可以异步完成，然后在消息完成时发送消息。如果您想确保最小化发送时间，异步日志记录会消除额外的开销，只需确保将任何时间数据发送到日志记录线程，以便在写入日志时准确无误。
Are you creating each message in the loop as that could be your overhead? This could be done asynchronously and then the messages sent as and when they are complete. Logging asynchronously would take away that additional overhead if you want to make sure that the sending time is minimized, just make sure to send any time data through to the logging thread so that it is accurate when logs get written.