Asynchronous ThreadSocketAcceptor, implementation via DI

Good afternoon. I would like to ask how the load is handled by an acceptor that is run using the ThreadSocketAcceptor of the QuickFix/n library? I didn't see a single asynchronous method. What happens if there are many messages from initiators across different sessions going through the acceptor? What are some best practices for creating acceptor services with QUickFix/n? I am only familiar with this standard implementation.

            try
            {
                SessionSettings settings = new SessionSettings(args[0]);
                IApplication app = new SimpleAcceptorApp();
                IMessageStoreFactory storeFactory = new FileStoreFactory(settings);
                ILogFactory logFactory = new FileLogFactory(settings);
                IAcceptor acceptor = new ThreadedSocketAcceptor(app, storeFactory, settings, logFactory);

                acceptor.Start();
                Console.WriteLine("press <enter> to quit");
                Console.Read();
                acceptor.Stop();
            }
            catch (System.Exception e)
            {
                Console.WriteLine("==FATAL ERROR==");
                Console.WriteLine(e.ToString());
            }

I also tried to create through BaskgroundService (WorkerService) using DI. But all services and registered as Singleton. I'm afraid that some logic on receiving, processing and forwarding of data can happen very slowly if everything will be executed in one thread through one object.

How can I avoid latency when there is one ThreadSocketAcceptor object and no asynchronous versions?

Incoming messages in all QFs are handled serially. This is intentional, to guarantee messages are received and processed in order. The caveat is that the QF/n callback implementations (i.e. your OnMessage() functions) should run and return fairly quickly, otherwise the message queue could eventually get backed up and your app will crash due to latency.

For message handling that may take longer, a common strategy is for OnMessage callbacks to push their messages into a work queue, and another worker thread will consume and process these messages.

(I must confess that I haven't yet written a commercial-grade QF/n Acceptor application. All of my serious QF/n projects have been with Initiator applications; my Acceptors were all for demos or testing of the aforementioned Initiators.)