[ https://issues.apache.org/jira/browse/TS-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-316: ----------------------------- Component/s: Network > Add a limit to the number of requests through a single KeepAlive connection > ---------------------------------------------------------------------------- > > Key: TS-316 > URL: https://issues.apache.org/jira/browse/TS-316 > Project: Traffic Server > Issue Type: Improvement > Components: Network > Reporter: Miles Libbey > Priority: Minor > Fix For: 2.3.0 > > > (was yahoo bug 1953368) > Original description > by Daniel Weaver 22 months ago at 2008-05-22 14:50 > This is a request to support a mechanism equivalent to Apache's > MaxKeepAliveRequests directive. > http://httpd.apache.org/docs/1.3/mod/core.html#maxkeepaliverequests > Basically, after the specified number of requests come through, a > "Connection: close" header is sent back to > the client to break the connection. This is useful because eternal Keep-Alive > essentially thwarts load balancers, and > can result in very uneven traffic over time (especially when restarting a TS > -- all connections are broken when it > shuts down, and then when it restarts it gets no new connections, because all > the clients have Keep-Alive sessions with > the other TS's that were behind the vip). > This conversation started in bug 1950760; see it for additional context. > Sherpa may experiment with inserting > "Connection: close" headers randomly in its response plugin in the meantime. > > > Comment 1 > by Chuck Neerdaels 22 months ago at 2008-05-22 15:11:32 > If it's added to the general TS path it'll break stuff. For instance > pipelining - if a client shoots 6 requests and you do a shutdown after > they get a response for 3, they have to unwind and reissue the requests. > Yes, clients could be written to deal with this, but there's a general > assumption that if you accepted and read the request, you intend to > answer it - barring something catastrophic. > The 1.1 spec is pretty ambiguous here. Closing connections when there's > a timeout generally flies, but inserting one midstream while under load > is going to backfire. Proxies just don't do that - even though servers > and clients can. > chuck > > Comment 2 > by Daniel Weaver 22 months ago at 2008-05-22 15:56:14 > Yeah... not a lot of commentary out there on the interaction between > pipelining and connection closing. I did find this > article that emphasizes, "Servers must therefore close each half of the > connection independently." > http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html#After_Tuning -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.