On 5/08/2013 12:58 p.m., babajaga wrote:
>> Erm. On fast or high traffic proxies Squid uses the disk I/O capacity to
> the limits of the hardware. If you place 2 UFS based cache_dir on one
> physical disk spindle with lots of small objects they will fight for I/O
> resources with the result of dramatic reduction in both performance and
> disk lifetime relative to the traffic speed. Rock and COSS cache types
> avoid this by aggregating the small objects into large blocks which get
> read/write all at once. <
>
> Really that bad ?
> As squid does not use raw disk-I/O for any cache type, OS/FS-specific
> buffering/merging/delayed writes will always happen, before cache objects
> are really written to disk. So, a-priori I would not see a serious
> difference between ufs/aufs/rock/COSS on same spindle for the same object
> size (besides some overhead for creation of FS-info for ufs/aufs).
It is not quite that simple. For a small object from UFS/AUFS/diskd
there is a file seek and load times, related small files all have the
same overhead. For Rock/COSS there is file seek and load time only for
the block in which that file exists (admittedly a little more overhead
loading the larger size of bytes), once it is loaded the additional
small objects have zero disk overheads. Since web objects are grouped in
"pages" objects which are very often loaded together within a short
timeframe the Rock/COSS method of storing to blocks in request order
often acts almost as efficiently as compacting the entire page into an
archive and delivering it in one HTTP request.
AUFS uses threads to get performance out of disk I/O controllers. There
are only a limited number the OS/controller can handle in parallel
before it starts to queue and all the others. Placing two such
directories on one disk doubles the controller load. Each thread will be
performing some operation on different parts of the disk so the seek
times are higher despite OS/FS tricks. If you throw too many read/write
at the controller buffering appears and slows the traffic down - not
good for performance. Also, unless you have disks with I/O rates faster
than your network pipes it is entirely possible that Squid will max out
the OS/FS layer capacity despite all the tricks it uses.
If you want to measure it, please do.
> COSS is
> out-of-favour anyway, because of being unstable, wright ?
Sort of. COSS is very much in favour for 2.7 installs, but for 3.2+ it
is it out of favour mostly because Rock was created as an improved
version instead of simply porting the COSS fixes.
Amos
Received on Mon Aug 05 2013 - 07:53:19 MDT
This archive was generated by hypermail 2.2.0 : Mon Aug 05 2013 - 12:00:17 MDT