Запрос прокси может ждать проверки учётных данных до достижения назначения. Если соединения без аутентификации и уже кэшированные проверки ведут себя иначе, чем новые входы, изучите путь аутентификации до изменения сетевых тайм-аутов.

Squid 6.13 запускает внешние помощники аутентификации. Медленный сервис каталогов, нечитаемый файл учётных записей, повторные завершения помощников или недостаток доступных помощников могут по-разному влиять на этот этап.

Найдите действительно ограничивающий этап

Проверьте журнал cache на ошибки запуска, завершения помощников и сообщения о перегрузке. Если доступна защищённая локальная статистика управления, изучите активность помощников там. Не открывайте административную точку публично только ради счётчиков.

Проверьте бэкенд независимо с тестовой учётной записью. Помощнику, который не завершает ни одной проверки, требуется исправление работы; больше копий не исправят ошибку пути или прав.

Число процессов — не параллельность протокола

Пример ограниченного пула процессов:

auth_param basic children 16 startup=2 idle=2

Максимальное число процессов, начальное число и требуемый запас простаивающих процессов здесь имеют разные цели. Значения иллюстративны. Согласуйте их с измеренным спросом на запросы и ограничениями соединений и ресурсов бэкенда.

Отдельная настройка concurrency меняет протокол общения Squid с помощником. Это не общий переключатель производительности. Включайте её только если конкретный помощник явно поддерживает требуемые идентификаторы каналов и одновременные запросы.

Кэширование учётных данных также влияет на необходимую частоту проверок. Сокращение срока действия при неизменном пуле помощников может увеличить работу даже при постоянном трафике просмотра.

После изменения разберите конфигурацию и сравните задержку аутентификации, ошибки и нагрузку бэкенда на репрезентативной разрешённой нагрузке. Успешный разбор подтверждает синтаксис, но не показывает, что новый пул быстрее или достаточно велик.

Похожие статьи