Performance is one of the biggest concerns for Squid administrators. As the load placed on Squid increases, disk I/O is typically the primary bottleneck. The reason for this performance limitation is due to the importance that Unix filesystems place on consistency after a system crash.
By default, Squid uses a relatively simple storage scheme
(ufs). All disk I/O is performed by the main Squid
process. With traditional Unix filesystems, certain operations always
block the calling process. For example, calling
open( ) on the Unix Fast Filesystem (UFS)
causes the operating system to allocate and initialize certain on-disk
data structures. The system call doesn’t return until these I/O operations
complete, which may take longer than you’d like if the disks are already
busy with other tasks.
Under heavy load, these filesystem operations can block the Squid process for small, but significant, amounts of time. The point at which the filesystem becomes a bottleneck depends on many different factors, including:
The number of disk drives
The rotational speed and seek time of your hard drives
The type of disk drive interface (ATA, SCSI)
Filesystem tuning options
The number of files and percentage of free space
Web caches such as Squid don’t usually come right out and tell you when disk I/O is becoming a bottleneck. Instead, response time and/or hit ratio degrade as load increases. The tricky thing is that response time and hit ...