Squidの認証ヘルパーがボトルネックになるとき

プロキシリクエストは、宛先へ届く前に資格情報の検証を待つことがあります。認証なしの接続やキャッシュ済みの検証と、新しいログインの挙動が違うなら、ネットワークのタイムアウトを変える前に認証経路を調べてください。

Squid 6.13は外部の認証ヘルパーを実行します。遅いディレクトリサービス、読めないアカウントファイル、ヘルパーの繰り返し終了、利用可能なヘルパーの不足は、この段階にそれぞれ異なる影響を与えます。

実際に制約している段階を探す

キャッシュログで起動失敗、ヘルパーの終了、過負荷メッセージを確認します。保護されたローカル管理統計があれば、そこで認証ヘルパーの活動を見ます。カウンターを得るためだけに管理用エンドポイントを公開しないでください。

テスト用アカウントでバックエンドを独立して検査します。一回の検証も完了できないヘルパーには機能上の修正が必要です。コピーを増やしても、パスや権限のエラーは直りません。

プロセス数とプロトコルの同時処理は別

上限のあるプロセスプールの例です。

auth_param basic children 16 startup=2 idle=2

最大プロセス数、初期数、確保したいアイドル数は、それぞれ役割が違います。値は例です。測定したリクエスト需要と、バックエンドの接続・リソース制限に合わせてください。

別のconcurrencyオプションは、Squidとヘルパーが通信するプロトコルを変えます。一般的な高速化スイッチではありません。そのヘルパーが必要なチャネル識別子と同時リクエストに明示的に対応している場合だけ有効にします。

資格情報のキャッシュは検証が必要になる頻度にも影響します。ヘルパープールを変えずに有効期間を短縮すると、ブラウジングの通信量が一定でも作業量が増える場合があります。

変更後は設定を構文解析し、代表的な許可された負荷で認証遅延、エラー、バックエンド負荷を比較します。構文解析の成功が示すのは構文であり、新しいプールの速度や容量が十分であることではありません。