セキュリティの意識が高まる中で、インターネット通信はプロキシを経由する構成になっていることが多いですが、プロキシでよく利用されいてる製品がi-FILTERです。
i-FILTERはデジタルアーツの製品ですが、運用管理していく中で重要なのがセッション数の管理です。
通常は、ユーザー数の１0%～30%の利用率を想定すればいいとありますが、使い方によってはセッション数が超過する可能性があります。
そこで、i-FILTERでスレッド数(同時接続数)が超過した場合の動作について公式サイトに書かれています。
「i-FILTER」 スレッド数(同時接続数)が不足した場合はどのような動作になりますか
https://www.pa-solution.net/daj/bs/faq/Detail.aspx?id=3039&dispNodeId=%22
対応バージョン：i-FILTER Ver.8 Ver.9 Ver.10
対応OS：すべてのOS
クライアントからのリクエストが「i-FILTER」で設定しているスレッド数を超えた場合、スレッドの処理待ち状態となり、Webアクセス遅延が発生します。
【通信シーケンス】
① クライアントは、「i-FILTER」で設定しているLISTENポートに対して
TCPセッションを確立します。 （3ウェイハンドシェイク）
このタイミングで、netstatコマンドを実施した際の
TCPステータスは「ESTABLISHED」となります。
② クライアントがHTTPリクエストを送信します。
（OSはTCP［ACK］を返します）
「i-FILTER」（if_proxy）のスレッドが不足していない場合は、
accept（）されフィルターやプロキシ通信などの処理が行われます。
スレッドが不足している場合、バックログと呼ばれるOSのキュー領域に
リクエストデータが滞留され、スレッドが空き次第accept（）されます。
③ 「i-FILTER」は、処理が完了したHTTPリクエストに対してレスポンスを返します。
上記の様に、スレッドが不足した場合は、OSのTCP階層までは
HTTPリクエストが送信されますが、バックログにキューイングされるため、
ユーザーはレスポンス遅延を体感します。
また、パケットキャプチャで確認した場合、②TCP［ACK］と
③「i-FILTER」からのレスポンスまでの間隔が空くことになります。
そして、設定しているスレッド数を超過すると、バックログキューに格納されるようになり、ここに格納された通信については遅延するようになります。 その為、スレッド数が超過する前に設定で調整をする必要があります。また、スレッド数を増やすとメモリを多く消費するようになる為、使用量が多い場合は、メモリの増設、台数の増加なども検討する必要があります。
