Калі памочнікі аўтэнтыфікацыі Squid становяцца вузкім месцам

Запыт проксі можа чакаць праверкі ўліковых даных перад дасягненнем мэты. Калі злучэнні без аўтэнтыфікацыі і ўжо кэшаваныя праверкі паводзяць сябе інакш за новыя ўваходы, вывучыце шлях аўтэнтыфікацыі перад зменай сеткавых часавых лімітаў.

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

Знайдзіце сапраўдны абмежавальны крок

Праверце журнал cache на памылкі запуску, завяршэнні памочнікаў і паведамленні перагрузкі. Калі ёсць абароненая мясцовая статыстыка кіравання, праверце актыўнасць памочнікаў там. Не адкрывайце пункт кіравання публічна толькі дзеля лічыльнікаў.

Праверце бэкенд незалежна з тэставым уліковым запісам. Памочніку, які не завяршае адну праверку, патрэбна выпраўленне працы; больш копій не выпраўляюць памылку шляху або правоў.

Колькасць працэсаў не азначае паралельнасць пратакола

Прыклад абмежаванага пула працэсаў:

auth_param basic children 16 startup=2 idle=2

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

Асобны параметр concurrency змяняе пратакол сувязі Squid з памочнікам. Гэта не агульны пераключальнік прадукцыйнасці. Уключайце яго толькі пры яўнай падтрымцы патрэбных ідэнтыфікатараў каналаў і адначасовых запытаў гэтым памочнікам.

Кэшаванне ўліковых даных таксама ўплывае на патрэбную частату праверак. Скарачэнне тэрміну дзеяння без змены пула можа павялічыць працу нават пры нязменным трафіку прагляду.

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