On 12/10/10 20:49, Squid at Iotti dot Biz wrote:
Da: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx]
Thank you for this. I'm sure quite a few people will find it useful.
I'm trying to make a few things "standard" in the helpers.
Please make this module accept the following command-line parameters:
-d debug info sent to stderr of the helper.
errors resulting in helper crash or exit prefixed with "FATAL: "
serious errors not resulting in crash prefixed with "ERROR: "
warnings about bad state which is and can be
auto-recovered prefixed
with "WARNING: "
Most debug messages are only informational. Is it ok to prepend these with
"INFO: "?
Good to hear nothing can go wrong ;-P
You can do what you like for things. We don't exactly have a standard
for things less than warning. Once the admin specifies -d it's fair game
for anything useful.
General informative traces need to be suppressed though unless -d is
given by the admin. Production servers can't afford to log much beyond
the starting up and shutting down messages. So even warnings need to
have importance or an available admin fix.
-h usage information about the helper command-line arguments.
I'm going to add these flags to the "luxguard" example helper script
included in the package, which resembles the script I really use in
production. The basic example is provided to be as basic as it could, and I
would like to keep it short as possible :)
FYI; I've been contemplating a framework for other languages off and on
for a while. The idea there so far is split between the framewrk itself
displaying the "standard" options then calling a client implemented
usage() function for the local ones. And the alternative of taking an
array/hash of options and doing a the display itself.
Please support the concurrency protocol. A module such as
this should be
perfect for abstracting the particular transaction protocol.
It will let
foreach() be used to process large numbers of lookups
quickly. Details on
implementing concurrency protocol can be found at
http://wiki.squid-cache.org/Features/Redirectors
I really want to support concurrency. Implementing it in the library is
really simple (just allowing the ID field in the request), but I should also
give an example script which takes some benefit from it. I think it should
be using perl threads (I don't see any benefit from concurrency, if I'm
going to process the requests one at a time in a FIFO queue), and I want to
be sure all other features are working before adventuring in threads.
It's worth it even for a FIFO queued helper. Squid can queue up a large
series of requests to each helper. Both in squid buffers and system IO
buffers. This results in a much reduced lag time between lines being
available to the helper reads. The resulting speed gain bumps right down
the chain into client service times at peak load.
Adding a truely threaded helper on top of that is extra goodness in the
cake.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.8
Beta testers wanted for 3.2.0.2
