Server statistics - The Polipo Manual
Description: The Polipo Manual

Next: PMM, Previous: Offline browsing, Up: Network

### 3.6 Server statistics

In order to decide when to pipeline requests (see Pipelining) and whether to perform Poor Man's Multiplexing (see Poor Mans Multiplexing), Polipo needs to keep statistics about servers. These include the server's ability to handle persistent connections, the server's ability to handle pipelined requests, the round-trip time to the server, and the server's transfer rate. The statistics are accessible from Polipo's web interface (see Web interface).

The variable ``serverExpireTime`' (default 1 day) specifies how long such information remains valid. If a server has not been accessed for a time interval of at least `serverExpireTime`, information about it will be discarded.

As Polipo will eventually recover from incorrect information about a server, this value can be made fairly large. The reason why it exists at all is to limit the amount of memory used up by information about servers.

The main use of server information is to decide whether to pipeline additional requests on a connection that already has in-flight requests. This is controlled by the variable `pipelineAdditionalRequests`; if it is `false`, no additional requests will be pipelined. If it is `true`, additional requests will be pipelined whenever possible. If it is `maybe` (the default), additional requests will only be pipelined following small requests, where a small request one whose download is estimated to take no more than `smallRequestTime` (default 5s).

Sometimes, a request has been pipelined after a request that prompts a very large reply from the server; when that happens, the pipeline needs be broken in order to reduce latency. A reply is large and will cause a pipeline to be broken if either its size is at least `replyUnpipelineSize` (default one megabyte) or else the server's transfer rate is known and the body is expected to take at least `replyUnpipelineTime` to download (default 15s).

The variable `maxPipelineTrain` defines the maximum number of requests that will be pipelined in a single write (default 10). Setting this variable to a very low value might (or might not) fix interaction with some unreliable servers that the normal heuristics are unable to detect.