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

[Brad House]

On 2/15/26 2:38 AM, Amos Jeffries wrote:

> On 15/02/2026 08: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.
>>
>
> When your networks I/O is faster than disk I/O, it is best not to 
> store at all.
>
> Like so:
>   acl fast_servers dst ...
>   store_miss deny fast_servers


Our Disk I/O is a few orders of magnitude faster than our internet 
speed, so caching should be able to serve much much faster.   I provided 
benchmarks of our Disk I/O measured with FIO on the VM.  We also want to 
be nice to upstream providers we are fetching from.


>> The VM I'm using currently has 4 cores, 16G RAM and 100G of usable 
>> space.
>
> You have configured your Squid to use 318 GB of cache. That will not 
> fit within 100 GB.


Sorry, I typo'd that number, it was supposed to say 400G:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda4       399G   14G  385G   4% /


>> 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.
>
> In this case I think you want to prevent small objects from being 
> stored in the disk cache. They can benefit from the fast network speed 
> and should not inflate your bandwidth use much.
>
>   cache_dir ... min-size=102400


We'd like to cache even small objects due to rate limiting we can hit at 
the remote sites.  We're spawning thousands of GHAs a day all, a large 
number of which fetch the same files (and we can't just change the fetch 
location as we are building OSS packages which fetch these packages as 
part of their build system).


>>
>> 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
>
> The above is the same as:
>   acl public src ipv4


Thanks


>
>> 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
>
> This is bad. You have an Open Proxy.
>
> Even though "public" does not include all the IPv6 range, it does 
> include every possible IPv4 machine on the Internet.


This is on a private internal network segment that only certain systems 
can access (like GHA runners).  We use our firewalls to control access.


>
>> http_access deny to_localhost
>> http_access deny to_linklocal
>> http_access deny all
>
> A series of deny followed by "deny all" is only useful if you are 
> supplying custom error pages.


Ok, these entries just came from the stock config install with the 
package from rocky.


> FYI, All these ...
>
>> 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
>>
>
> ... are only useful when the repository service does not obey HTTP/1.1 
> properly. Otherwise they are detrimental.
>
> Good example, are those package tar/deb files. In a repository, 
> packages contain their version details in the filename and URL. Once 
> created they remain unchanged forever.
>
> Whereas, the above rules are forcing Squid to stop using any cached 
> object and replace it once these files reach 90 days old.


That would obviously assume the upstream server is sending proper 
cache-control headers, I haven't verified if that's the case.  I took 
these rules from the squid-deb-proxy package, from what you're saying it 
sounds like that package shouldn't exist anymore.

Are there any particular things I should try?  One use said to use rock 
... are there particular settings?  Are there any known performance 
issues with the 6.10 release I'm using?

Thanks.

-Brad