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
[email protected]
https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-users
