Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

acceptor need threadpool? #850

Open
zhoufudun opened this issue Aug 2, 2024 · 0 comments
Open

acceptor need threadpool? #850

zhoufudun opened this issue Aug 2, 2024 · 0 comments

Comments

@zhoufudun
Copy link

my thinking:

QuickFixJ is built on top of MINA, and MINA allows configuring the number of Processor threads. Assuming there are 10,000 connections, generally, configuring the Processor threads to 100-200 is sufficient. Let’s say we configure 100 Processor threads; on average, each Processor thread handles the read and write requests of 100 clients.

Currently, in QuickFixJ, a separate thread is allocated for each client at the business layer to execute business logic. Messages can be initiated by the client or sent by the server to the client. Even if the messages from the client are processed quickly and responses are sent promptly, these responses need to be executed by MINA’s Processor threads to be truly sent to the remote client.

Therefore, the performance bottleneck lies in MINA rather than QuickFixJ. QuickFixJ can fully utilize a thread pool at the business layer for execution,Additionally, a thread pool can mitigate the risk of creating too many threads.

Is it necessary to do this? If so, I’ll create a pull request。 look forward to hearing from you on this matter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant