[squid-users] Re: HTTP/1.1 pipelining

2014-03-10 Thread babajaga
But mgr:client_list shows different type of info, as far as I can see. It
shows current client connections, whereas mgr:pconn shows past connection
statistics (effectiveness)
My squid2.7:

/usr/local/squid/etc#  ../sbin/squid27 -v
Squid Cache: Version 2.7.STABLE9-20110824

/usr/local/squid/etc# squidclient -p  -h 127.0.0.1 -U manager -W ?
mgr:pconn
HTTP/1.1 200 OK
Date: Mon, 10 Mar 2014 08:06:33 GMT
Content-Type: text/plain
Expires: Mon, 10 Mar 2014 08:06:33 GMT
Connection: close

Client-side persistent connection counts:

req/
conn  count
  -
   0  15160
   1   9681
   2   2801
   3   1547
.
 203  2
 208  1
 216  1
 220  1
 231  1
 250  1

Server-side persistent connection counts:

req/
conn  count
  -
   1  95899
   2   2066
   3   1049

  83  1
  99  1
 104  1
 110  1
 112  1
 132  1


So the first part of 2.7-pconn statistics is dropped on later
squid-versions, although quite interesting, I think. May be, I should file a
bug or feuture request ?




--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/HTTP-1-1-pipelining-tp4658574p4665114.html
Sent from the Squid - Users mailing list archive at Nabble.com.


Re: [squid-users] Re: HTTP/1.1 pipelining

2014-03-10 Thread Alex Rousskov
On 03/07/2014 08:00 PM, babajaga wrote:

 then the following in
 http://www.squid-cache.org/Doc/config/pipeline_prefetch/
 is misleading:
 
 If set to N, Squid
   will try to receive and process up to 1+N requests on the same
   connection concurrently.
 
 Note the concurrently.

I think the latest documentation is correct (but I am biased because I
helped write it). I cannot see what is misleading about it. If, after
Amos' clarifications, you still think that something is misleading here,
please clarify what it is, and we will try to fix.


 For older versions of squid, it is stated differently.

The old documentation was very vague, but worked borderline OK for the
on/off case (N was either 0 or 1). Newer Squids support arbitrary N
values (with the same old zero default).


Cheers,

Alex.



Re: [squid-users] Re: HTTP/1.1 pipelining

2014-03-10 Thread Alex Rousskov
On 03/10/2014 02:20 AM, babajaga wrote:
 But mgr:client_list shows different type of info, as far as I can see. It
 shows current client connections, whereas mgr:pconn shows past connection
 statistics (effectiveness)
...
 So the first part of 2.7-pconn statistics is dropped on later
 squid-versions, although quite interesting, I think. May be, I should file a
 bug or feuture request ?

FWIW, I agree that knowing the number of requests per from-client
connection is useful. If this is not shown anywhere, a bug report or a
feature request might help, and a quality patch adding those stats would
be welcomed. mgr:pconn would be the right place to show those  stats for
all Squid sides that use persistent connections (whether pooled by Squid
itself or by the clients talking to Squid).

Reporting request concurrency level (i.e., the used pipeline depth) when
pipelining with clients is enabled would also be useful.


Thank you,

Alex.



[squid-users] Re: HTTP/1.1 pipelining

2014-03-09 Thread babajaga
Thanx for clarification. Then to this one, pls:

Trying squid 3.4.3, I get


squidclient -p nnn -U ? -W ??? mgr:pconn
HTTP/1.1 200 OK
Mime-Version: 1.0
Date: Fri, 07 Mar 2014 15:15:01 GMT
Content-Type: text/plain
Expires: Fri, 07 Mar 2014 15:15:01 GMT
Last-Modified: Fri, 07 Mar 2014 15:15:01 GMT
Connection: close


 Pool 0 Stats
server-side persistent connection counts:

req/
conn  count
  -
   1 43
   2  5
   4  3
   5  1
   6  2
   7  5
   8  2
   9  2
  10  1
  11  2
  12  1
  13  2
  14  2
  15  1
  17  1
  19  1
  25  1
  26  1
  27  1
  34  1
  36  1
  41  1
  60  1
  70  1
 110  1

 Pool 0 Hash Table
 item 0: 127.0.0.1:8887
 item 1: 127.0.0.1:8887
-

Does that mean, absolutely no persistent conn/pipelining to the client (FF,
pipelining enabled; Chrome) ?
from squid.conf:
pipeline_prefetch 3
client_persistent_connections on 
http_port nnn tcpkeepalive=3,3,125


BUT:
With almost same squid.conf (besides pipeline_prefetch=on) for my squid2.7 
squidclient -p nnn -U ? -W ??? mgr:pconn
always shows me quite a few client side persistent conns with request counts
up to about 50.

So either I am missing something in squid.conf, upgraded from 2.7 - 3.4.3,
a bug in squidclient or a bug/change in behaviour between 2.7/3.4.3 ?
(Note: Using 3.4.3, I can always see Connection: keep-alive in the
response header. )






--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/HTTP-1-1-pipelining-tp4658574p4665110.html
Sent from the Squid - Users mailing list archive at Nabble.com.


Re: [squid-users] Re: HTTP/1.1 pipelining

2014-03-09 Thread Amos Jeffries

On 2014-03-10 02:53, babajaga wrote:

Thanx for clarification. Then to this one, pls:

Trying squid 3.4.3, I get


squidclient -p nnn -U ? -W ??? mgr:pconn
HTTP/1.1 200 OK
Mime-Version: 1.0
Date: Fri, 07 Mar 2014 15:15:01 GMT
Content-Type: text/plain
Expires: Fri, 07 Mar 2014 15:15:01 GMT
Last-Modified: Fri, 07 Mar 2014 15:15:01 GMT
Connection: close


 Pool 0 Stats
server-side persistent connection counts:

req/
conn  count
  -
   1 43
   2  5
   4  3
   5  1
   6  2
   7  5
   8  2
   9  2
  10  1
  11  2
  12  1
  13  2
  14  2
  15  1
  17  1
  19  1
  25  1
  26  1
  27  1
  34  1
  36  1
  41  1
  60  1
  70  1
 110  1

 Pool 0 Hash Table
 item 0: 127.0.0.1:8887
 item 1: 127.0.0.1:8887
-

Does that mean, absolutely no persistent conn/pipelining to the client 
(FF,

pipelining enabled; Chrome) ?


No. Client connections are not pooled, never have been. They are shown 
in the mgr:client_list report.




from squid.conf:
pipeline_prefetch 3
client_persistent_connections on
http_port nnn tcpkeepalive=3,3,125


BUT:
With almost same squid.conf (besides pipeline_prefetch=on) for my 
squid2.7

squidclient -p nnn -U ? -W ??? mgr:pconn
always shows me quite a few client side persistent conns with request 
counts

up to about 50.


Not sure. Squid-2.6/2.7 were a fork off Squid-2.5. It is very possible 
somebody made it show the client connections and the mainline of Squid 
never got the change. I've spent a lot of time these last few years 
cross-porting little things like that.




So either I am missing something in squid.conf, upgraded from 2.7 - 
3.4.3,

a bug in squidclient or a bug/change in behaviour between 2.7/3.4.3 ?
(Note: Using 3.4.3, I can always see Connection: keep-alive in the
response header. )



Well its a difference of behaviour certainly.


Amos


[squid-users] Re: HTTP/1.1 pipelining

2014-03-07 Thread babajaga
 They still have to be read and processed in
order.
Squid reads requests out of the client connection one at a time and
processes them.  

Could this be a bit more clarified ?
 I mean, when squid started to process the first request from pipeline
(request forwarded to destination), will squid also start to process the
next request from pipeline in parallel, or wait, until previous one
completed ?

Are there mayor differences in pipelining between squid2.7 and newest
versions ?
Actually, I am located in a remote area, ping from my client to squid is
about 300-350ms. Theoretically, pipelining should be of benefit here, as I
also suspect, my wireless ISP limits the amount of parallel conns.





--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/HTTP-1-1-pipelining-tp4658574p4665093.html
Sent from the Squid - Users mailing list archive at Nabble.com.


Re: [squid-users] Re: HTTP/1.1 pipelining

2014-03-07 Thread Alex Rousskov
On 03/07/2014 04:19 AM, babajaga wrote:
 They still have to be read and processed in order.
 Squid reads requests out of the client connection one at a time and
 processes them.


 Could this be a bit more clarified ?
  I mean, when squid started to process the first request from pipeline
 (request forwarded to destination), will squid also start to process the
 next request from pipeline in parallel, or wait, until previous one
 completed ?

By default, Squid will not process more than one concurrent request
received on the same connection. For details, please see
pipeline_prefetch in squid.conf.documented or
http://www.squid-cache.org/Doc/config/pipeline_prefetch/

Alex.



[squid-users] Re: HTTP/1.1 pipelining

2014-03-07 Thread babajaga
Alex,

then the following in
http://www.squid-cache.org/Doc/config/pipeline_prefetch/
is misleading:

If set to N, Squid
will try to receive and process up to 1+N requests on the same
connection concurrently.

Note the concurrently.
For older versions of squid, it is stated differently.



--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/HTTP-1-1-pipelining-tp4658574p4665100.html
Sent from the Squid - Users mailing list archive at Nabble.com.


Re: [squid-users] Re: HTTP/1.1 pipelining

2014-03-07 Thread Amos Jeffries
On 8/03/2014 4:00 p.m., babajaga wrote:
 Alex,
 
 then the following in
 http://www.squid-cache.org/Doc/config/pipeline_prefetch/
 is misleading:
 
 If set to N, Squid
   will try to receive and process up to 1+N requests on the same
   connection concurrently.
 
 Note the concurrently.
 For older versions of squid, it is stated differently.
 

Just a fix of the documentation. pipeline_prefetch has always been about
concurrency/parallel processing even though it did not say so.

All Squid will handle multiple requests on a persistent connection
regardless of what pipeline_prefetch is set to. They are still received
and responses delivered completely serially. HTTP/1.x requires that
guarantee.

pipeline_prefetch simply determines how many of the client requests can
have been read in and not yet responded to.

Many processing actions like parsing, validation, adaptation, cache
lookup and sometimes even fetching from a fast server can be done on
those requests entirely without having responded to the client. When
pipeline_prefetch is enable Squid attempts to do what it can for each
request while its waiting to be able to deliver the response.

Amos