On 2024-06-28 01:38, Nishant Sharma wrote:
On 27/06/24 23:06, Alex Rousskov wrote:
and how your traffic tickles them, SMP Squid without atomic locks
might become very slow! We do not (and, IMO, should not) optimize
performance for environments without lock-free atomics!
I see the following options for going forward:
* Comment out the assertion, void your warranty, and hope for the best.
* Audit relevant code to confirm that the assertion is safe to remove.
* Find a usable OS/environment that has lock-free 64-bit atomics.
I am not a developer, so it will take me some help to get the code and
repercussions of it's modification understood.
In our use case, we do not use caching at all except a small in-memory
cache of say 64MB.
Squid is used for access control with external acl helper and SSL Bump
where SMP used to help with version 4.x.
Would it be catastrophic to comment out the assertion and then remove
relevant code for such a use case where there is no disk cache available
for probable corruption?
I do not know the answer to your question. SMP performance penalties are
often smaller for smaller cache sizes, but cache size is not the only
performance-affecting locking-sensitive parameter, so YMMV.
> ... and then remove relevant code ...
Just to avoid a misunderstanding: Other than commenting out the
assertion line, no code removal is suggested in my bulleted list quoted
above. The first bullet is a speculative "remove the assertion and see
what happens" experiment. The second bullet is about reviewing existing
code (without code modifications) to validate the need for that
assertion. That audit/validation is required to remove the assertion
from official Squid sources. That need (and that decision) do not depend
on cache sizes and other deployment specifics.
HTH,
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
