Re: I was wondering about SMP and requests loadbalance.

On 7/10/2013 12:31 p.m., Eliezer Croitoru wrote:
> There is a difference between a forard proxy and a LB proxy..
> For example haproxy can handle 100k requests per sec of proxying traffic.
>
> IN a case that I want to load balance traffic to squid instances I have
> considered using squid as Amos suggested but I am not sure yet how much
> load one instance can take using one cpu??

Our test benchmark proxy runs at over 950 req/sec ( I think on a 1.2GHz
CPU ?) while being loaded down with a full LAMP stack of software.

I have some customers whose Squid proxy over 20k req/sec while being
slowed down by constant re-authentication and several external ACL
helper lookups.

Your mileage will vary depending on the specific CPU and intallation
specific details.

> Let say turning on instances that listens on a serial number of IPs
> (local) 10.100.101.1-30 on port 3129 and a LB that sits at
> 10.100.101.200 that loads the balance between the proxies in IP level by
> SRC+DST IP pairs in the kernel level seems to me a bit smarter and
> efficient.

Perhapse. You will find that in the ExtremeCarpFrontend configuration
examples.

This is affected by some code in Squid which limits the number of
accept() done per listening port, and prioritizes those accept() over
read()/write() while there are FD available to accept the connections.

> I am not sure about the above assumption and wanted to understand:
> When I will use squid as a LB non cacheing instance what would be the
> maximum load it can take?

The answer will vary depending on the network speed (Mbps/Gbps), RTT
delay to the remote servers, and how long any given server response takes.
In artificial tests using a localhost server that responded at 100Mbps
with small responses (simulating HTTP/1.1 revalidation traffic ona
reverse proxy) I was able to hit 300k req/sec with squid-3.1 on a 1.6GHz
CPU before ApacheBench started showing errors. That version was some
10-15% slower than the current releases judging by other factoids.

> In the above example squid will be sitting between the the client to the
> cache proxies.
> So each request will be using CPUx2 to only parse the request... am I
> right about that?

Yes.

> let say we want to just use the main instance as LB not parsing at all..

That is not possible with Squid. And if you think about it you will see
that one should be using TCP level load balancer for that task instead.
Routing done via Squid is only useful when the routing criteria involve
HTTP details. In which case one must parse to identify those details. So
making it possible in Squid is a waste of effort.

> so we will have eventually one instance that only gets the request from
> the client and loadbalance it in the application level towards the other
> instances with a very low consumption of resources.
>
> I am not saying that there is a request for this feature but how complex
> is it to add a "http_port 3124 loadbalancer" ??
> I think that squid has a lot of power already in hands and adding this
> specific feature will be a nice addition to the code.

With SMP Squid this is easy to setup multi-layered workers. The details
are already in the wiki under SmpCarpCluster configuration example.

Otherwise use iptables level routing / port forwarding for the frontend
instead of Squid. The ExtremeCarpFrontend configuration has details on
the rules requlred

> In a case we dont want to mess it all up etc..
> Haproxy uses something that called proxy-protocol which is described
> probably here:
> http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt
>
> basically it's seems to me like the procol example is like this:
> "PROXY TCP4 192.168.0.1 192.168.0.11 56324 443\r\n"
> like line at the begining of the incomming connection.
> the v2 is a binary form header which is describe in section 2.2

The main benefit of that is for offloading the HTTPS frontend to some
other software (ie stunnel in the examples).

In Squid we try to avoid adding complication like that. Squid supports
https_port for the HTTPS use case, and we advise proper packet
forwarding and routing instead of NAT'ing for the load balancing use
case. For interception proxy we explicitly do not support sending client
traffic directly to a remote proxy - it is preferred to keep the traffic
local to avoid a great many problems.

> The above protocl gives the option of full transparent proxy
> implementation to be real..

No. Triangular routing is what will happen if the TPROXY and the client
are on different networks.

  SYN : client A => ISP => stunnel gateway => ISP 2 gateway
=>TPROXY
  SYN+ACK : client A <= ISP <= stunnel gateway <= ISP 2 gateway <= TPROXY
HTTP request: client A => ISP => stunnel gateway => ISP 2 gateway =>TPROXY

{ SYN: TPROXY => origin server
{ SYN+ACK: client A <= origin server
{ ... client drops unexpected SYN+ACK packet.
{ ... TPROXY server connection times out.

HTTP error: client A <= ISP <= stunnel gateway <= ISP 2 gateway <= TPROXY

> As an example for the option of using tproxy for that pourpose we can
> divide the proxy network into 2 layers.
> the ring between the client and the proxy which intercepts the connecion
> and another layar between the proxies to the internet.
> it's more of two rings proxy system.

Administrators can prevent the above packet routing problems ONLY if
they have full control of the routing rules at all locations on the flow
between TPROXY and server. In real-world this is very unlikely to be
true. Therefore TPROXY must be done on the same network as the client.

NOTE: that one network can be layered with fancy routing setup
internally. But it still must be the same administrative network.

Amos
Received on Mon Oct 07 2013 - 01:22:05 MDT