[squid-users] Debugging a slow Squid?
ngtech1ltd at gmail.com
Sat Nov 28 18:49:49 UTC 2020
I must add that to verify any browsing speed issue there are couple very specific tests which should be tested:
- DNS response speed, response content ie A/AAAA/CNAME etc..
- Basic traceroute tests
- periodic Ping tests
- CPU load(top, htop, others..)
- curl/wget/other specific pages speed download tests
- Another http/socks proxy (tinyproxy/others, see the root folder of the onedrive shared link)
Depend on the up-stream line.
A microwave link can work well for 50-100 Meters however when rain drops pop here and there you would even see 3000ms plus++ delays.
There are ways to compensate on these but these are measurable enough so you would know about them.
I would start with:
How can I make Squid work almost with no DISK?
access_log none ? access_log stdio:/dev/null ?
cache deny all ?
cache_mem 0 MB ?
Adding a local dns cache might resolve many issues(bind, unbound, dnsmasq..)
Without writing a book.
What might cache_mgr interface has to say about this?
Email: ngtech1ltd at gmail.com
From: squid-users <squid-users-bounces at lists.squid-cache.org> On Behalf Of Alex Rousskov
Sent: Saturday, November 28, 2020 6:24 PM
To: roee klinger <roeeklinger60 at gmail.com>; squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Debugging a slow Squid?
On 11/28/20 7:00 AM, roee klinger wrote:
> I am aware of the <tr> in the Squid log, but does it show the time it
> took Squid to process the request or does it also include the time it
> took the request to even get to Squid (for example the time from the
> router to Squid, from the user to the router, etc)?
Overall, do not expect Squid to measure what happens before the HTTP
request header is received. Squid could (and should and eventually will)
measure more than it does now when it comes to the beginning of the
transaction, but often there is just not enough information to measure
the client-Squid propagation/communication delay for the initial TCP
packet(s) or for the initial HTTP request packet on a previously used
Specifically, %tr logformat code logs the difference between master
transaction start time and master transaction logging time.
* According to %tS documentation, Squid currently considers the master
transaction started when a complete HTTP request header initiating the
transaction is received from the client.
* Currently, Squid logs the master transaction when the client-Squid
transaction that was handling the client HTTP request gets destroyed.
Usually, that destruction happens when Squid receives the entire request
from the client and sends the entire response to that client.
> What would be the best way to isolate, inspect, and improve Squid
> performance, regardless of network performance?
One could write a book answering this question, but I would start by
running atop to exclude system bottlenecks (memory, CPU, disk) first.
Once system/global bottlenecks are eliminated, you may be able to detect
processing stages that slow down the transaction the most by sending
representative test requests.
squid-users mailing list
squid-users at lists.squid-cache.org
More information about the squid-users