Коли помічники автентифікації Squid стають вузьким місцем

Запит проксі може чекати перевірки облікових даних до досягнення призначення. Якщо з’єднання без автентифікації та вже кешовані перевірки поводяться інакше за нові входи, вивчіть шлях автентифікації до зміни мережевих тайм-аутів.

Squid 6.13 запускає зовнішніх помічників автентифікації. Повільний сервіс каталогів, нечитабельний файл облікових записів, повторні завершення помічників або недостатня їх кількість можуть по-різному впливати на цей етап.

Знайдіть справді обмежувальний крок

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

Перевірте бекенд окремо з тестовим обліковим записом. Помічнику, що не завершує навіть одну перевірку, потрібне виправлення роботи; більше копій не усунуть помилку шляху чи прав.

Кількість процесів — не паралельність протоколу

Приклад обмеженого пулу процесів:

auth_param basic children 16 startup=2 idle=2

Максимальна кількість процесів, початкова кількість і бажаний запас вільних процесів тут мають різні цілі. Значення ілюстративні. Узгодьте їх із виміряним попитом та обмеженнями з’єднань і ресурсів бекенду.

Окреме налаштування concurrency змінює протокол спілкування Squid з помічником. Це не загальний перемикач продуктивності. Умикайте його лише за явної підтримки потрібних ідентифікаторів каналів і одночасних запитів цим помічником.

Кешування облікових даних також впливає на необхідну частоту перевірок. Скорочення строку дії за незмінного пулу може збільшити роботу навіть за сталого трафіку перегляду.

Після зміни розберіть конфігурацію та порівняйте затримку автентифікації, помилки й навантаження бекенду на репрезентативному дозволеному навантаженні. Успішний розбір підтверджує синтаксис, але не доводить, що новий пул швидший або достатньо великий.