On 1/5/19 5:51 AM, Santos Das wrote: > Hi Christian, > > > We see that at the end of the load run, the connections at the TCP > server remain in CLOSE_WAIT state. We didn’t see this for single call. > Also, I wanted to tell you that all our connection are initiated from a > single IP as that is the load balancer IP and we are behind that.
The single IP should hardly matter. > We also observed that it gets stuck in the CLOSE_WAIT state and remains > there forever , i.e Sockets are seen in this state even after the > default of TCP connection timeout. What kind of method do you use to generate the response? > From all my study, it points out the TCP stack will keep the connection > in CLOSE_WAIT state till the application call close on the socket. Right, so the question now is why the socket is not closed. Two reasons are clearly coming together: (1) you disabled the timeout, (2) for some reason MHD believes the response is not done. So we should also figure out why your response is not considered "finished" by MHD. > Do we know when MHD call close normally ? Is there any instrumentation > that could tell us why /whether FIN is sent from the Server or NOT ? You could just 'strace' and look for the close() call, but that won't tell you where exactly the issue is.
signature.asc
Description: OpenPGP digital signature
