Asterisk's HTTP server connections handling

We’re trying to use the asterisk http server to originate calls, we’ve been pretty successful so far. However during some load tests, we noticed that every http request that carries an Originate action would open up a new TCP connection to asterisk’s http port, instead of reusing the previous connection. We suspect the reason is that every http response from asterisk’s http server features a “Connection: close” header, which essentially tells the client app to close the connection. Therefore, the client app will initiate another connection for its next http request. Meanwhile, asterisk still thinks the connection is alive (according to the display in “manager show connected”), and a netstat on the asterisk machine still shows the connections as being active (state is TIME_WAIT).

We tried reducing the value of the httptimeout parameter in manager.conf. Although that does have an effect, the http connections are reset by asterisk at the rate of one every 5 seconds. So if we generate 100 http requests in the first minute and we use httptimeout=60, over the next minute we only get rid of 12 of them, over the 3rd minute we get rid of 12 more and so on. Practically we cannot consistently initiate calls at a rate higher than one every 5 seconds, because we cannot close the http connections in time, and that, sooner or later, will choke the server down. Obviously, any AMI action requests other than Originate would add up their own http connections.

Anyone can help with a suggestion on what to check, or a workaround that would still use the http AMI. Our asterisk is 11.8 running on a centos machine.

TIME_WAIT is not active and the timeout is built into TCP. It is the delay after a connection is closed to allow all packets from it to exit the network.

Yeah, i just figured that a few mins ago… so the connection is closed client-side, but the server still has it hanging around for a while, which is admittedly normal OS functionality.

One more thing i tried was recompiling asterisk so that it doesnt send the “Connection: close” header in the response, but didnt make any difference. What i’m not so sure about, maybe someone can explain, is how the http digest authentication ends up turning into the similar Action: Login that i used to do when i was using a direct tcp connection. Although it may be silly, I’m trying now to see how an initial Action=Login sent in an http request, followed by the Action=Originate, will play out. (Because no, i dont send a prior Action=Login.)