Hi All,
I need a help on this issue. On heavy network traffic with squid
running, link bandwidth is not utilized properly. If I bypass squid,
my link bandwidth is utilized properly.
Updated topology:
=
(10 Mbps
Hey Saravanan,
The main issue is that we can try to support you in a very basic way but
note that if it's a BUG it cannot be fixed later rather then porting a
patch manually or to try newer versions of squid.
Sometimes it's a bit difficult to upgrade but you can compile squid
without
On 5/12/2013 1:45 p.m., Eliezer Croitoru wrote:
Hey Saravanan,
The main issue is that we can try to support you in a very basic way but
note that if it's a BUG it cannot be fixed later rather then porting a
patch manually or to try newer versions of squid.
Going by the description here and
Hi All,
I am doing a small test for bandwidth measurement of my test setup
while squid is running. I am running a script to pump the traffic from
client browser to Web-server via Squid box. The script creates
around 50 user sessions and tries to do wget of randomly selected
dynamic URL's.
On Tuesday 26 November 2013 at 11:37, SaRaVanAn wrote:
Hi All,
I am doing a small test for bandwidth measurement of my test setup
while squid is running. I am running a script to pump the traffic from
client browser to Web-server via Squid box.
Er, do you really mean you are sending data
On Tue, Nov 26, 2013 at 5:16 PM, Antony Stone
antony.st...@squid.open.source.it wrote:
On Tuesday 26 November 2013 at 11:37, SaRaVanAn wrote:
Hi All,
I am doing a small test for bandwidth measurement of my test setup
while squid is running. I am running a script to pump the traffic from
On 23.01.13 05:12, Amos Jeffries wrote:
IIRC we tried that but it resulted in early cloure of CONNECT tunnels
and a few other bad side effects on the tunnelled traffic.
Due to the way tunnel.cc and client_side.cc code interacts (badly) the
client-side code cannot know whether the tunnel is
On 22/01/2013 3:31 a.m., Steve Hill wrote:
On 11.01.13 00:06, Amos Jeffries wrote:
So it seems apparent that after Squid delivers the clear-text
response, it abandons the socket but never closes it. From looking in
the source, this is client_side.cc, and it has a comment:
// XXX: Can this
On 11.01.13 00:06, Amos Jeffries wrote:
So it seems apparent that after Squid delivers the clear-text
response, it abandons the socket but never closes it. From looking in
the source, this is client_side.cc, and it has a comment:
// XXX: Can this happen? CONNECT tunnels have
On 11/01/13 00:06, Amos Jeffries wrote:
Okay. So the source of the problem is that Squid thinks there is
something using the socket, but it never got into the tunnel code which
would have closed it?
Is the 403 message being generated inside Squid or by ICAP?
The 403 isn't generated by
On 09/01/13 21:07, Amos Jeffries wrote:
Does the CONNECT request contain Connection:close or
Connection:keep-alive? Squid supports keep-alive on CONNECT requests in
these situations where the CONNECT size is known and may be waiting for
another client request.
The client sends
On 11/01/2013 7:11 a.m., Steve Hill wrote:
On 09/01/13 21:07, Amos Jeffries wrote:
Does the CONNECT request contain Connection:close or
Connection:keep-alive? Squid supports keep-alive on CONNECT requests in
these situations where the CONNECT size is known and may be waiting for
another client
I have a busy Squid 3.2.3 server that constantly has a huge number of
connections tied up in CLOSE_WAIT (i.e. at the moment it has 364
ESTABLISHED but 3622 in CLOSE_WAIT).
tcp1 0 :::172.23.3.254:8080
:::172.23.2.158:49615 CLOSE_WAIT 32303/(squid-1)
All of these
On 09/01/13 10:14, Steve Hill wrote:
I have a busy Squid 3.2.3 server that constantly has a huge number of
connections tied up in CLOSE_WAIT (i.e. at the moment it has 364
ESTABLISHED but 3622 in CLOSE_WAIT).
tcp1 0 :::172.23.3.254:8080 :::172.23.2.158:49615
CLOSE_WAIT
On 10/01/2013 1:28 a.m., Steve Hill wrote:
On 09/01/13 10:14, Steve Hill wrote:
I have a busy Squid 3.2.3 server that constantly has a huge number of
connections tied up in CLOSE_WAIT (i.e. at the moment it has 364
ESTABLISHED but 3622 in CLOSE_WAIT).
tcp1 0
We use Squid 3.1.12 with TrendMicro IWSVA as ICAP server and early responses
enabled.
I see a lot of ICAP connections hanging in FIN_WAIT1 state (with large
Send-Q) on IWSVA and CLOSE_WAIT state on squid box (with large Recv-Q).
Cache manager shows them as idle connections.
Can it be one
No. Squid should be draining its queue, even if leaving the connections
idle. Being in the idle pool sets a read to abort/close the socket on
FIN or on excess data.
This does sound like those ICAP incomplete reply problems. Though how
its getting into Squids idle pool without the act of
Just for interest I'll give icap_persistent_connections off a try.
Daniel
Now it looks in cache manager like that (former idle):
81 Socket0 7097799383 ICAP-Server:1344
icap://ICAP-Server/RespMod-Service
No asterisk
Daniel
Connections with FIN_WAIT1 state on ICAP server side seem ESTABLISHED at
squid.
ICAP-closed connection.
Idle pconn in Squid have readers set listening for FIN to arrive and
close the FD. This is strange but not conclusive.
Looks a bit like the FIN never arrived.
Squid
On 31/05/11 00:17, Daniel Beschorner wrote:
Connections with FIN_WAIT1 state on ICAP server side seem ESTABLISHED at
squid.
ICAP-closed connection.
Idle pconn in Squid have readers set listening for FIN to arrive and
close the FD. This is strange but not conclusive.
Looks a bit like
Which manager report? idle connections is a bit messy in the current
stables. It should only refer to the persistent, open, but not currently
in-use connections. The tag is left set sometimes and shows up on closed
ones.
Under File Descriptor Allocation.
If Squid actually sees them as
On 27/05/11 23:50, Daniel Beschorner wrote:
Which manager report? idle connections is a bit messy in the current
stables. It should only refer to the persistent, open, but not currently
in-use connections. The tag is left set sometimes and shows up on closed
ones.
Under File Descriptor
On 16/05/11 20:10, Daniel Beschorner wrote:
We use Squid 3.1.12 with TrendMicro IWSVA as ICAP server and early responses
enabled.
I see a lot of ICAP connections hanging in FIN_WAIT1 state (with large Send-Q)
on IWSVA and CLOSE_WAIT state on squid box (with large Recv-Q).
Cache manager shows
We use Squid 3.1.12 with TrendMicro IWSVA as ICAP server and early responses
enabled.
I see a lot of ICAP connections hanging in FIN_WAIT1 state (with large Send-Q)
on IWSVA and CLOSE_WAIT state on squid box (with large Recv-Q).
Cache manager shows them as idle connections.
Can it be one of the
24 matches
Mail list logo
