Re: [PATCH] Accelerator load balancing #2

Sorry for the late response. Hope you are still around.

You have been awarded a link from devel.squid-cache.org.

Your ideas is very interesting, but I'd prefer it it was implemented using
peer selection. This way the load algorithm can be used both in accelerators
and proxies, and also makes it more obvious how to integrate into SNMP.

See also the squid-rproxy branch <http://devel.squid-cache.org/rproxy/>.
It is a rework of how to set up reverse-proxying using Squid, centered around
cache_peer rather than the awkward and very limited httpd_accel* directives.

Regards
Henrik Nordström
Squid Hacker

On Sunday 22 October 2000 07.44, richard@iguana.co.nz wrote:
> Ok, attached is the latest accel mode load balancing patch, vast
> improvement over previous one yadda yadda.
>
> I do not recommend including this in distribution squid at this stage,
> although I hope one day it'll reach that :)
>
> The patch is against 2.3-STABLE4, and at this stage is believed to be
> stable.
>
> Description:
>
> This patch allows squid, in httpd_accel mode, to act as a multiple-machine
> load-balancing/failover/caching engine for any number of backend
> webservers. The load-balancing algorithm is considerably advanced from
> preivous versions, it now tracks average time-to-complete over the last
> 100 connections to the given node, and then calculates which node is
> liable to serve the current request first. It maintains a track of
> currently running requests thus balancing to a slower machine if the
> faster machine is too busy, etc. The engine uses the first AVG_LEN (by
> default, 100) requests to calibrate, distributing amoung the nodes evenly.
>
> Failover is implemented by taking a certain set of errors returned by
> squid on a server connection, and marking the node dead for 60 seconds.
> The request is then transfered transparently by squid to another node.
> Nodes marked dead are not given any requests during their dead time.
>
> It is possible to dynamically reconfigure the server using the standard
> squid reload, in-progress requests will continue, all new requests will
> use the new configuration, allowing you to explicitly remove or add nodes
> without downtime.
>
> Configuration:
>
> I currently use the following lines in my accel config:
>
> httpd_accel_host virtual
> httpd_accel_port 80
> httpd_accel_uses_host_header on
> httpd_accel_balance_targets web3.dmz web2.dmz web1.dmz
>
> Note that you may also do:
>
> httpd_accel_balance_targets web3.dmz:80 web3.dmz:90 web2.dmz
>
> etc, if you do not specify the port, it will use the httpd_accel_port as
> default.
>
> Log information:
>
> This patch dumps information every 30 seconds to the cache.log. This is
> not ideal and it would be nice to incorporate the statistics into the snmp
> engine or something but it works for now, format:
>
> 2000/10/22 16:18:57| balance: web3.dmz queue 0 average 0.076025 total
> 0.000000 reqs 82 hps 0.117913 2000/10/22 16:18:57| balance: web2.dmz queue
> 0 average 0.120233 total 0.000000 reqs 83 hps 0.117913 2000/10/22 16:18:57|
> balance: web1.dmz queue 0 average 0.129913 total 0.000000 reqs 83 hps
> 0.147391
>
> The queue is the number of currently in-progress requests for that node,
> average is the average time taken to serve a request, total is 0 during
> calibration, otherwise it is queue*average, reqs is the number of requests
> served by that node, and hps is the last 30 seconds hits-per-sec.
>
> Code:
>
> Various outstanding issues with the quality of the code. While externally
> it has moved much close to the squid look&feel, internally it still uses
> my own list code, I will have to get around to converting that, and there
> is a bit of commenting out of debugging lines :) Mostly its cool, but my
> natural perfectionist bent will probably force a cleanup a little later
> on. If there are any other issues anyone notices, I'd be happy to take a
> look at them.
>
>
>
> If anyone wants any more information, or has any suggestions, let me know.
> The patch is included here for your own interest and use, I aint taking
> any responsibility for people who use it and crash'n'burn. That said, its
> been pretty solid here. It should scale up pretty well, so as long as
> squid itself can handle it, things should be fine no matter how many nodes
> you add.
>
> Richard.
>
> [ Experienced linux system/network/software designer/enginner ]
> [ available contract/perm, http://richard.exorsus.net/cv.html ]
> [ c/pl/php/js/opengl/apache/squid/route/secure/mail/dns/fw/++ ]
Received on Sun Nov 04 2001 - 05:19:07 MST