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

[Brad House]

AUFS cache is currently being used.  I'm pretty sure I tried rock after 
and noticed worse performance but I don't recall trying to tune it.

On 2/14/26 5:40 PM, Jonathan Lee wrote:
> Is it rock cache and how many workers are you using ?
> Sent from my iPhone
>
>> On Feb 14, 2026, at 11:45, Brad House <brad at brad-house.com> 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
>>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20260214/f7a26ce1/attachment-0001.htm>