[squid-users] Performance issue -- serving from cache

[Alex Rousskov]

On 2026-02-14 14:45, Brad House wrote:
> I've got a squid deployment where serving from cache can be slower than 
> an uncached download.  I'm seeing speeds of around 50MB/s when serving 
> from cache, which is much slower than anticipated.  Infact, when hitting 
> fast upstream servers, serving of a non-cached asset is faster (even 
> though its still hitting squid to fetch it).
> 
> I'm thinking there's got to be something wrong with my squid 
> configuration, I'm currently running on Rocky Linux 10 with Squid 6.10-6.
> 
> The VM I'm using currently has 4 cores, 16G RAM and 100G of usable 
> space.  I used fio to measure disk performance and I got
> 
>   * Random Write: 3629MiB/s (1MB block), 33.2k (4k block) IOPS
>   * Random Read: 8391MiB/s (1MB block), 43.5k (4k block) IOPS


What speed to you get when Squid serves the object from the memory 
cache? Do not configure a disk cache for this test to make sure that 
Squid is not reading from disk...

I cannot help with AUFS cache_dirs, but _if_ AUFS code uses 4KByte I/O 
blocks, then 50MByte/s you are measuring is equivalent to 12K IOPS which 
is arguably not that bad for that long-neglected AUFS code (compared to 
"raw" 44K IOPS performance you measured with fio)!

Please note that I am not trying to imply that rock cache_dir with a 
large slot-size setting would work faster than AUFS. And even if 
properly configured rock does work faster than AUFS, I would be really 
surprised if Squid can approach Traffic Server performance! The two 
projects had vastly different focus and resources.


HTH,

Alex.


> Adding more cpu cores or ram doesn't appear to impact performance.
> 
> The underlying infrastructure is made up of hypervisors with dual 100G 
> uplinks, both the client and squid run on the same hypervisor cloud.  
> Network performance is not the issue.
> 
> As a test, I spun up Apache Traffic Server and get over 800MB/s when 
> serving from cache.
> 
> We have a large on site build system that spins up runners for GitHub 
> actions, and they're constantly fetching large assets from the internet 
> for each build, hence our desire for a caching proxy.  We'd rather not 
> switch to Apache Traffic Server as that doesn't have SSL bump capability 
> (we haven't yet enabled that capability in squid, however).  Hopefully 
> there's a simple configuration I'm missing.
> 
> Just for testing I was pulling large image via http that is below my max 
> object size: 
> http://mirrors.edge.kernel.org/ubuntu-releases/20.04.6/ubuntu-20.04.6-live-server-amd64.iso
> 
> Configuration below:
> 
> acl public src 0.0.0.0/0
> acl SSL_ports port 443
> acl Safe_ports port 80
> acl Safe_ports port 443
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localhost manager
> http_access deny manager
> http_access allow public
> http_access deny to_localhost
> http_access deny to_linklocal
> http_access deny all
> http_port 8080
> maximum_object_size 2 GB
> cache_dir aufs /var/spool/squid 325632 16 256
> cache_mem 1000 MB
> maximum_object_size_in_memory 102400 KB
> coredump_dir /var/spool/squid
> refresh_pattern -i (/cgi-bin/|\?) 0    0%    0
> refresh_pattern deb$   129600 100% 129600
> refresh_pattern udeb$   129600 100% 129600
> refresh_pattern tar.gz$  129600 100% 129600
> refresh_pattern tar.xz$  129600 100% 129600
> refresh_pattern tar.bz2$  129600 100% 129600
> refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
> refresh_pattern \/Release(|\.gpg)$ 0 0% 0 refresh-ims
> refresh_pattern \/InRelease$ 0 0% 0 refresh-ims
> refresh_pattern \/(Translation-.*)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
> refresh_pattern changelogs.ubuntu.com\/.*  0  1% 1
> 
> 
> Thanks!
> 
> -Brad
> 
> 
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users