I have done some experiments raising the backlog value, and it is possibly a bit better, I have to test it more. Even if it works I would of course like to avoid having to rely on a patched qpid. Also, maybe some internal queues or similar should be modified to handle this?
I have not seen transport errors in the clients, but this may be because reconnection is enabled. I am unsure on what the reconnection feature actually does, I never seen an on_connection_open where connection.reconnection() returns true. Perhaps it is only useful when a connection is established and then lost? On Thu, Jun 2, 2022 at 1:44 PM Ted Ross <tr...@redhat.com> wrote: > On Thu, Jun 2, 2022 at 9:06 AM Fredrik Hallenberg <megahal...@gmail.com> > wrote: > > > Hi, my application tends to get a lot of short lived incoming > connections. > > Messages are very short sync messages that usually can be responded with > > very little processing on the server side. It works fine but I feel > > that the performance is a bit lacking when many connections happen at the > > same time and would like advice on how to improve it. I am using qpid > > proton c++ 0.37 with epoll proactor. > > My current design uses a single thread for the listener but it will > > immediately push incoming messages in on_message to a queue that is > handled > > elsewhere. I can see that clients have to wait for a long time (up to a > > minute) until they get a response, but I don't believe there is an issue > on > > my end as I as will quickly deal with any client messages as soon as they > > show up. Rather the issues seems to be that messages are not pushed into > > the queue quickly enough. > > I have noticed that the pn_proactor_listen is hardcoded to use a backlog > of > > 16 in the default container implementation, this seems low, but I am not > > sure if it is correct to change it. > > Any advice apppreciated. My goal is that a client should never need to > wait > > more than a few seconds for a response even under reasonably high load, > > maybe a few hundred connections per seconds. > > > > I would try increasing the backlog. 16 seems low to me as well. Do you > know if any of your clients are re-trying the connection setup because they > overran the server's backlog? > > -Ted >
