Squid 认证 helper 何时会成为瓶颈

代理请求到达目标之前，可能先等待凭据验证。如果无需认证的连接、已有缓存的验证与新登录表现不同，先检查认证路径，再考虑修改网络超时。

Squid 6.13 会运行外部认证 helper。目录服务缓慢、账户文件不可读、helper 反复退出，或可用 helper 不足，都可能以不同方式影响这一阶段。

找出实际受限的环节

检查缓存日志中的 helper 启动失败、退出和过载消息。如果有受保护的本地管理统计，就在那里查看认证 helper 活动。不要仅为获取计数器而将管理端点公开。

使用测试账户单独检查后端。连一次验证都无法完成的 helper，需要先修复功能正确性；多启动几个副本不能修复路径或权限错误。

进程数量不等于协议并发

一个有上限的进程池示例：

auth_param basic children 16 startup=2 idle=2

这里的最大进程数、初始数量和期望的空闲可用数量有不同用途。数值仅作示例，应根据测得的请求需求，以及后端连接和资源限制调整。

独立的 concurrency 选项会改变 Squid 与 helper 通信的协议，它不是通用性能开关。只有该 helper 明确支持所需的通道标识和同时请求时，才启用它。

凭据缓存也会影响需要验证的频率。缩短凭据有效期却保持 helper 池不变，即使浏览流量恒定，也可能增加工作量。

修改后，解析配置，并在具有代表性的授权工作负载下比较认证延迟、错误和后端负载。解析成功仅能确认语法，不能证明新进程池更快或足够大。