Re: [squid-users] Squid isn't using persistent server-side connections upon POST/PUT/DELETE

 NP: inserted a few empty lines to make the text paragraphs
 identifiable.

 On Tue, 11 Oct 2011 20:25:06 +0200, Franz Kafka wrote:
> Good evening Squid experts,
> We have a serious issue with persistent connections. We are testing a
> large REST-Application which heavily depends on caching and correct
> cache behaviour in particular concering the rather scarcely used

 Then if you have not already done so please look over the compliance
 checklist at:
  http://wiki-squid-cache.org/Features/HTTP11

 It covers milestone releases in the common Squid versions which
 advertise 1.1. There are still numbers of networks using Squid 2.6 and
 2.5 though which have 1.0 compliance. And networks using un-rated
 releases. So this is not a complete picture, just an idea of what can be
 expected out in the Internet.

 HTTP/1.1 correct behaviour is an ongoing effort. Sponsorship is
 appreciated, working patches even more so.

 <snip>
> So only if the PUT doesn't contain an HTTP-Body, the squid<->server
> connection is persistent. The client<->squid connection on the other
> hand is persistent (we use both the non-standard Proxy-Connection:
> keep-alive and the correct hopy-by-hop Connection: keep-alive in our
> request).

 You should be able to drop Proxy-Connection entirely. Squid-3.1 emits
 it by mistake in some releases. All squid accept Connection:.

> Here is a detailed example of a successful GET:
> 1. Client sends to Squid:
> GET http://192.168.14.194/ HTTP/1.1Cache-Control: no-cache,
> max-age=0Date: Tue, 11 Oct 2011 16:53:44 GMTContent-Length: 0Accept:
> application/x-java-serialized-object,
> application/x-java-serialized-object+xmlHost:
> 192.168.14.194User-Agent: Restlet-Framework/2.1rc1Connection:
> keep-aliveProxy-Connection: keep-alive
> 2. Squid sends to Server:
> GET / HTTP/1.1Date: Tue, 11 Oct 2011 16:53:44 GMTContent-Length:
> 0Accept: application/x-java-serialized-object,
> application/x-java-serialized-object+xmlHost:
> 192.168.14.194User-Agent: Restlet-Framework/2.1rc1Via: 1.1 localhost
> (squid/3.1.11)X-Forwarded-For: 192.168.14.194Cache-Control: no-cache,
> max-age=0Connection: keep-alive
> 3. Server sends to Squid:
> HTTP/1.1 200 OKDate: Tue, 11 Oct 2011 16:53:44 GMTServer:
> Restlet-Framework/2.1rc1Vary: Accept-Charset, Accept-Encoding,
> Accept-Language, AcceptConnection: keep-aliveContent-Length:
> 5Content-Type: text/plain; charset=UTF-8
> blubb
>
> 4. Squid sends to Client:
> HTTP/1.0 200 OKDate: Tue, 11 Oct 2011 16:53:44 GMTServer:
> Restlet-Framework/2.1rc1Vary: Accept-Charset, Accept-Encoding,
> Accept-Language, AcceptContent-Length: 5Content-Type: text/plain;
> charset=UTF-8X-Cache: MISS from localhostX-Cache-Lookup: MISS from
> localhost:3128Via: 1.0 localhost (squid/3.1.11)Connection: keep-alive
> blubb
> 5. Both TCP-Connections Client<->Squid and Squid<->Server are still
> open and used for subsequent GET Requests.
> And now an example of a failed persistent connection between squid
> and server:
> 1. Client sends to Squid:
> POST http://192.168.14.194/ HTTP/1.1Cache-Control: no-cache,
> max-age=0Date: Tue, 11 Oct 2011 16:53:46 GMTContent-Length:
> 4Content-Type: text/plain; charset=UTF-8Accept:
> application/x-java-serialized-object,
> application/x-java-serialized-object+xmlHost:
> 192.168.14.194User-Agent: Restlet-Framework/2.1rc1Connection:
> keep-aliveProxy-Connection: keep-alive
> test
> 2. Squid does Threeway-SYN-SYN/ACK-ACK-Handshake with Server and
> sends:
> POST / HTTP/1.1Date: Tue, 11 Oct 2011 16:53:45 GMTContent-Length:
> 4Content-Type: text/plain; charset=UTF-8Accept:
> application/x-java-serialized-object,
> application/x-java-serialized-object+xmlHost:
> 192.168.14.194User-Agent: Restlet-Framework/2.1rc1Via: 1.1 localhost
> (squid/3.1.11)X-Forwarded-For: 192.168.14.194Cache-Control: no-cache,
> max-age=0Connection: keep-alive
> test
> 3. Server replies over that connection:
> HTTP/1.1 200 OKDate: Tue, 11 Oct 2011 16:53:45 GMTServer:
> Restlet-Framework/2.1rc1Vary: Accept-Charset, Accept-Encoding,
> Accept-Language, AcceptConnection: keep-aliveContent-Length:
> 4Content-Type: text/plain; charset=UTF-8
> test
> 4. Wih FIN-ACK the Squid closes the connection to the server and
> replies to the client:
> HTTP/1.0 200 OKDate: Tue, 11 Oct 2011 16:53:46 GMTServer:
> Restlet-Framework/2.1rc1Vary: Accept-Charset, Accept-Encoding,
> Accept-Language, AcceptContent-Length: 4Content-Type: text/plain;
> charset=UTF-8X-Cache: MISS from localhostX-Cache-Lookup: MISS from
> localhost:3128Via: 1.0 localhost (squid/3.1.11)Connection: keep-alive
> test
> 5. For the subsequent requests, the client uses the same connection
> to the Squid, which is still open and the Squid opens a new
> connection
> to server to forward a PUT or POST. If the Squid isn't used at all,
> the client<->squid connection is persistent.

> To us that behaviour seems inconsistent and faulty. RFC 2616 doesn't
> make any comments about closing a persistent connection if a
> POST/PUT/DELETE was send. Thus it's not reasonable at all. Is it a
> bug?

> Btw, yesterday we already reported an unrelated TCP issue of Squid,
> which totally abandons a Connection if a Request having an If-Match
> Header results in a Cache Hit
> (http://bugs.squid-cache.org/show_bug.cgi?id=3379 ).
> We are very thankful for any suggestions concerning our persistent
> connection problem, which keeps us up at night. We are trying to run
> a
> benchmark comparison and the TCP-Connection-kills totally ruin the
> performance.

 At least you are getting realistic results out of it.

 I think sending keep-alive then FIN is a bug. if in fact that FIN is
 actually coming from Squid. The rest seems perfectly compliant
 behaviour. Annoying and inefficient, but compliant.

 Check you have server_persistent_connections ON. I think OFF there
 would send close and FIN. But its possible to be what you see.

 RFC 2616 also specifies that POST is non-idempotent. So there are
 tricky conditions around whether new connections are required. Whether a
 particular Squid uses persistence or not varies. Though they should at
 least be keeping it alive afterwards since Content-Length is present.

 PUT and DELETE, should have gone through the persistent connections
 AFAIK, but may have been caught up in the same logics as POST.

 Please also check whether this still occurs with the latest daily
 bundle before reporting. 3.1.11 is a few months old now and we have had
 a focus on performance fixes this year.

 Amos
Received on Wed Oct 12 2011 - 00:49:25 MDT