Re: ICAP connections under heavy loads

On 08/27/2012 03:29 AM, Alexander Komyagin wrote:
> Hi! My setup is Squid 3.2.1 + C-ICAP Antivirus.
>
> I noticed that in simulated production setup (e.g. 1200 http requests
> per sec) there are dozens connections established from squid to c-icap
> server, and even after the last client request timeouts, these
> connections are still opened/opening.
>
> tcp 0 0 127.0.0.1:1344 127.0.0.1:51352 ESTABLISHED
> tcp 722 0 127.0.0.1:1344 127.0.0.1:51500 ESTABLISHED
> tcp 0 0 127.0.0.1:51374 127.0.0.1:1344 ESTABLISHED
> ...

> Is this the intended behavior?

ICAP connections are maintained separately from HTTP client connections
and may be persistent. If you have N or more concurrent HTTP requests
that need adaptation, it is likely that you will have N or more
concurrent ICAP connections. Some or all of those connections will
outlast the last HTTP client.

The same is true for the HTTP server connections.

In summary, there are at least three mostly independent pools of
possibly persistent connections: HTTP client-side, HTTP server-side, and
ICAP. There are squid.conf options to control how long an idle
persistent connection is being kept in the pool.

> Also there are a lot of "BUG: Orphaned connection" messages in my
> cache.log under those conditions. I found out that they are caused by
> Xaction destruction after client request timeout, getting
> noteInitiatorAborted() before connection is established in the
> corresponding ConnOpener job. I temporarily fixed that by notifying
> ConnOpener (if any) in the Xaction::swanSong().

Please consider opening a bug report and/or submitting a patch fixing
the problem.

IIRC, Amos has mentioned that he left the BUG message their to collect
all buggy cases that he could not identify through code analysis. I
recall seeing these BUG messages as well, but I do not remember whether
they were caused by the same sequence of events.

Thank you,

Alex.
Received on Mon Aug 27 2012 - 17:57:56 MDT