Кога помощниците за удостоверяване на Squid стават тясно място

Прокси заявка може да чака проверка на данните за вход, преди да стигне целта. Ако връзките без удостоверяване и вече кешираните проверки се държат различно от новите влизания, проверете пътя за удостоверяване преди смяна на мрежовите времеви лимити.

Squid 6.13 изпълнява външни помощници за удостоверяване. Бавна директорийна услуга, нечетим файл с акаунти, повтарящи се излизания на помощници или недостатъчно налични помощници могат да повлияят различно на този етап.

Намерете действително ограничаващата стъпка

Проверете cache лога за грешки при стартиране, излизания на помощници и съобщения за претоварване. Ако има защитени локални управленски статистики, вижте активността там. Не излагайте управленска крайна точка публично само за получаване на броячи.

Тествайте бекенда независимо с тестов акаунт. Помощник, който не може да завърши една проверка, изисква поправка на функционирането; повече копия не поправят грешка в пътя или разрешенията.

Броят процеси не е едновременност на протокола

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

auth_param basic children 16 startup=2 idle=2

Тук максималният брой, началният брой и желаната свободна наличност имат различни цели. Стойностите са примерни. Съобразете ги с измереното търсене и ограниченията за връзки и ресурси на бекенда.

Отделната опция concurrency променя протокола за комуникация между Squid и помощник. Тя не е общ превключвател за производителност. Включете я само ако помощникът изрично поддържа нужните идентификатори на канали и едновременни заявки.

Кеширането на данни за вход също влияе колко често е нужна проверка. Скъсяване на валидността без промяна на пула може да увеличи работата дори при постоянен трафик на браузъра.

След промяна анализирайте конфигурацията и сравнете забавяне на удостоверяване, грешки и натоварване на бекенда при представително разрешено натоварване. Успешният анализ потвърждава синтаксиса; не показва, че новият пул е по-бърз или достатъчно голям.