On 2026-02-23 11:13, Brad House wrote:
On 2/18/26 11:04 AM, Brad House wrote:
On 2/15/26 8:00 PM, Alex Rousskov wrote:
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.
I'll need to wait until the weekend to give the memory-only cache a
try. Do you have any suggested Rock settings I should try while I'm
testing things? I'm ok wasting disk space on smaller items if it
means it can serve from cache faster in general.
Unfortunately, I cannot efficiently guide you through these
optimizations right now, but, FWIW, I wrote a few optimization notes for
rock some time ago:
https://wiki.squid-cache.org/Features/RockStore#performance-tuning
I am not implying that the above notes are applicable to your case.
I get 350MB/s serving from memory cache which is much more reasonable.
Great!
Also, I tried Rock again, and inspecting the logs further it appears it
isn't caching at all and always serving direct. I'm getting these
errors in the log:
2026/02/23 10:58:35 kid1| ERROR: /var/spool/squid/rock exception: check
failed: pending->writeRequest->len <= Ipc::Mem::PageSize()
exception location: IpcIoFile.cc(381) push
current master transaction: master60
This ERROR looks like a sign of a Squid bug. I have not investigated it,
but if you are setting rock slot-size to more than 32KB, please try to
lower that value to 32768. Testing Squid performance while Squid emits
those ERRORs is probably meaningless.
I guess I could bump the memory up in the VM to something like 64G so
the hotter items can be served faster an only needs to go to disk either
after restart or when an item is no longer in memory cache.
If your workload hot subset fits into that larger memory cache, it may
be the best first optimization step. There is also memory_cache_mode,
but I cannot predict whether changing that would help or hurt in your
use case.
Good luck,
Alex.
_______________________________________________
squid-users mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-users
