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.
