[squid-users] Worker-specific configurations considered evil

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Fri, 22 Mar 2013 15:23:26 -0600

Hello,

    Please do not interpret the following as a hidden criticism of any
specific solution being discussed on the list. I just want to make an
important _general_ point after seeing _many_ attempts to use SMP macros
and conditionals in squid.conf.

IMO, official SMP support is limited to cases not using worker-specific
configurations.(*)

Any worker-specific configuration is essentially a hack or workaround. A
small hack is often the best temporary solution. The bigger the hack,
the more likely it will go wrong sooner. Something like using
${process_number} macro in access log format to see which worker got the
request is a small hack. On the opposite end of the spectrum is a huge
hack of giving each worker its own configuration file using conditionals.

SMP macros and conditionals are very handy tools. However, when deciding
whether to make worker-specific configs, please keep in mind that such
configs may not be officially supported (now and especially in the
future). In other words, any "my worker-specific config does not work or
stopped working" support request is far less likely to be officially
addressed than a similar request not involving a worker-specific
configuration.

In some cases, we will have to break currently working worker-specific
configurations to make progress with SMP support.

SMP support goal is to have a single Squid configuration for all
workers, with no macros or conditionals. SMP-unaware features may
require hacks or exceptions to work in SMP environment. The number of
such features decreases with time. When a feature transitions from
SMP-unaware to SMP-aware, its worker-specific configuration may break.
This does not mean that one must not use SMP-unaware features in SMP
environments, but one should understand the trade-offs involved before
committing to their long-term use.

Thank you,

Alex.
(*) That is not the only SMP limitation, of course.
Received on Fri Mar 22 2013 - 21:23:28 MDT

This archive was generated by hypermail 2.2.0 : Sat Mar 23 2013 - 12:00:05 MDT