On 06/02/12 16:00, Robert Segall wrote:
On Sat, 2012-02-04 at 12:20 -0500, Dave Steinberg wrote:
I had requested some ability to select load balancing policy apart from
priorities, specifically I was hoping for a 'least-connections' policy.
Several remarks here:
- Pound never used round-robin. It still does not.
- Connection counting is not a very useful metric. The same back-end may
be used in several contexts (perhaps even with different addresses or
ports), so the number of connections is not very informative.
- you may want to look at the DynScale code - it probably does some of
what you need.
Clustering via multiple includes of the same file is clever. I'd
suggest a note in the man page about that, since I think it's a common
thing.
Re: include_dir - if you sort the files alphabetically, then order is
defined.
...and at a later date you add one file by accident to that directory
and nothing works any longer. Besides, think of the next sysadmin, who
will need to work with your installation.
I'd say that if they add a file and break it - then surely it's their
fault??
Most systems with an IncludeDir will work on an numerical/alphebetised
list.. this is why you see things like the following:-
mez@supine % ls -1 /etc/apt/apt.conf.d
00trustcdrom
01autoremove
01proxy
10periodic
15update-stamp
20archive
20changelog
20dbus
50unattended-upgrades
70debconf
99update-notifier
If someone adds in a file that breaks the system - it's their fault!
With regards to the next sysadmin thing - I know I personally would,
rather have things seperated out into manageable chunks, rather than
have one MASSIVE configuration file. (think what would happen if you put
all your apache config into a single file...)
I would also question the use case for it: do you really need hundreds
of files included? If it is just a handful it is not so difficult to
include them explicitly.
Same could be said for apache. It allows us to 1) develop a similar
system like a2ensite a2enmod et al, and 2) means if we want to add, say,
a new listener, we only have to add a file, not edit multiple files.
Therefore, reducing the possibility that we break something. (typoing
the filename for example)
As, in theory, we should have already tested the new file on a dev
environment - then putting it up to live is as simple as adding a new
file - rather than potentially editing in a typo into the main config to
include the new file.
Yes, I know dev environment/RCS negates that, but seriously - how many
sysadmins do you know who actually use RCS properly for their configs?
I currently have 12 listeners, each with at least 3 services, some with
up to 20 - most of these have at least 2 backends, and we generally add
a new site every 3 months or so... my singular config files is already
becoming unwieldy and unmanageable... and on at least 3 occasions I've
edited the wrong bit because the file is such a hassle to maintain as it is.
--
To unsubscribe send an email with subject unsubscribe to [email protected].
Please contact [email protected] for questions.
