Sachin Malave wrote:
Dear Amos,
Thank you for updating wiki.squid-cache.org/Features/SmpScale, now
ideas are more clear, I have already started working on the
architecture that is proposed...
Thank you for your thanks.
Which part and which layer are you working towards now?
(the earlier work you have already done was towards mid-layer)
If it was top-layer there are a few speed bumps we've already identified
and not yet documented:
Missing Pieces (most to least difficult):
* Mechanism to replace SquidConf:cache_dir (proposal cache_disk
/media/path SIZE ) - a set of disk entries. Master instance to load and
portion off each child instance with one or more disks. The child
instance to determine what types of storage (old SquidConf:cache_dir
types) to be stored there and what sizes will fit in the disk max given.
* Mechanism to handle many SquidConf:http_port and other listening
port directives - Master instance doing accept and passing to children?
or all children listening on all ports on a first-accept-wins basis?
* Mechanism needed to replace existing method of master instance
"monitoring" for a dead child instance. Perhapse listening socket based?
* Mechanism to split cache_mem between all child instances. Or do we
leave this as-is and call it a per-instance allocation?
* Mechanism to keep unique_hostname unique per instance? do we even
need to? is it safer to consider the whole bunch of instances one unique
"host" and leave the existing code preventing complicated loops paths
between instances?)
Amos
--
Please be using
Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
Current Beta Squid 3.1.0.15
