Re: Persistent Connection Issue

On Thu, 2006-04-13 at 15:22 -0700, Isaac Cheung wrote:
 
> I finally got persistent connections showing up after I specified
> http_versions = ["1.0"] under the definitions of the server and robot
> in the workload.
>  
> Interestingly, when I specified http_versions=["1.1"] for both,
> persistent connections would never be established.  Using tcpflow, i
> see that the robot sends out HTTP1.1 header with a "Proxy-Connection:
> close".  And, the Server responded with a HTTP1.0 header with a
> "Proxy-Connection: close" (as expected.).

Understood.

> So there are really 2 problems:
>  
> 1. Server was using HTTP1.0 even when it had been instructed to use
> 1.1.

This, and the "close" option on the server side could be due to your
proxy sending HTTP/1.0 requests to the server, without the "keep-alive"
connection option. Recall that persistency is managed hop-by-hop and not
end-to-end. Do you know what request the proxy was sending to the
Polygraph server (protocol version and Connection header)?

> 2. HTTP1.1 sent a "Proxy-Connection: close" in the header when
> persistent connection is enabled.

That does not sound good indeed! I would like to investigate this
further.

Bugs notwithstanding, I am not sure what could have caused that unless
you were looking at the last request on a connection: About 25% of
connections will have just one request because of the zipf(16)
distribution properties. Also, all connections will have "Connection:
close" for the last request. The average connection "length" should be
about 5 requests. Thus, if my math is right, the chance that a given
request is the last request on a connection is about 40%, even if the
proxy never closes the connection "prematurely".

BTW, the command below will show you the distribution histogram:

	distr_test --distr 'zipf(16)'

If you have a tcpdump or tcpflow output saved (showing a few complete
connections with multiple requests and responses on all sides) or if you
can make a new one, please send it to me privately along with your
workload file.

Thank you,

Alex.


> Alex Rousskov <[email protected]> wrote:
>         On Fri, 2006-04-07 at 12:02 -0700, Isaac Cheung wrote:
>         > I have previously executed workload with polygraph 2.8.1 on
>         Linux
>         > 2.4.21-40 having pconn_use_lmt set to zipf(16). But, I found
>         out from
>         > the SQUID persistent conn utilitization histrograms that
>         there were
>         > only 1req connections accepted meaning there were no
>         persistent conn
>         > established.
>         > 
>         > To validate the proxy setup, I further tested it with a
>         connected
>         > browser and persistent connections were indeed established.
>         > 
>         > With pconn_use_lmt set to zipf(16) and http_versions set to
>         the
>         > default are there other parameters that I need to set in
>         order to
>         > enable pconn?
>         
>         I do not think so. There is also a related persistent
>         connection timeout
>         parameter (idle_pconn_tout), but it is optional. I would do
>         the
>         following:
>         
>         1. Check that you are setting pconn_use_lmt on the right
>         side(s). The
>         option is valid for Polygraph robots and servers.
>         
>         2. Grab a few HTTP requests and responses (e.g., via
>         tcpdump/show or
>         ethereal). Check whether Polygraph is _not_ sending
>         "Connection: close"
>         HTTP header in the HTTP/1.1 request. Check that Squid is
>         sending
>         "Connection: keep-alive" in the HTTP/1.0 response. If the HTTP
>         versions
>         or message headers differ from the expected ones, we may be
>         able to find
>         the culprit.
>         
>         > Or are there other conditions that will cause persistent
>         connections
>         > not to be used?
>         
>         On Polygraph side, errors and similar abnormal conditions
>         close a
>         persistent connection. The server (including Squid) can signal
>         connection close by sending "Connection: close" in an HTTP/1.1
>         response
>         or sending nothing in an HTTP/1.0 response. On Squid side,
>         there may be
>         many other factors (e.g., load).
>         
>         Sorry for the delayed response. Please keep me posted on your
>         progress.
>         
>         Thank you,
>         
>         Alex.
>         
> 
> 
> 
> 
> ______________________________________________________________________
> New Yahoo! Messenger with Voice. Call regular phones from your PC and
> save big.