これは、ColdFusion 以外のプラットフォームに関連している可能性があります。
IIS 6 のログは、ColdFusion ページへの複数のリクエストに対して [接続タイムアウト] で設定された 120 秒よりもはるかに長い (30 分) "所要時間" を報告します。
現時点では、ColdFusion が応答していなかったと思います。IIS がこれほど長く待機するのではなく、要求を停止することを望みます。
これを強制する IIS 設定はありますか?
これは、ColdFusion 以外のプラットフォームに関連している可能性があります。
IIS 6 のログは、ColdFusion ページへの複数のリクエストに対して [接続タイムアウト] で設定された 120 秒よりもはるかに長い (30 分) "所要時間" を報告します。
現時点では、ColdFusion が応答していなかったと思います。IIS がこれほど長く待機するのではなく、要求を停止することを望みます。
これを強制する IIS 設定はありますか?
このシナリオは、クライアントが原因の場合、スロー HTTP DoS攻撃と見なすこともできます。Microsoft はこれをプロトコルのバグであり、IIS の弱点ではないと見なしているため、IIS は (少なくとも遅い POST 本体に対しては) 十分な保護を提供しません。この場合、サーバーがそれ自体を実行していると思いますが。
確認事項:
遅いのはリクエストなのか、サーバーのレスポンスなのかについては言及していません。応答が遅い場合は、 MinFileBytesPerSecパラメータを微調整してみてください 。デフォルトでは、クライアントが毎秒 240 バイト未満でダウンロードしている場合、接続が切断されます。
120 秒の IIS タイムアウトはアイドルタイムアウトであることを思い出してください。クライアントが 120 秒以内に数バイトを送受信する限り、そのタイマーはリセットされ続けます。
この長い待ち時間がすべてのページで発生しているのか、それとも常にいくつかの特定のページで発生しているのかについては言及していません. CF スクリプトが別の外部接続を行っている可能性があります。たとえばCFQUERY
、これはCF タイムアウトの影響を受けませんが、接続先のサーバーのタイムアウトの影響を受けます。内部で timeout 属性を使用すると、CFQUERY
これを防ぐことができます。
また、Coldfusion の設定についても触れていません。IIS タイムアウト設定が Coldfusion JRUN コネクタ ISAPI フィルタによって無視されている可能性があるため、Coldfusion Administrator で設定を確認する必要があります。特に、Timeout Requests afterが変更されているかどうかを確認してください。それでもデフォルトの 60 秒のままである場合は、コードをチェックして、そこでオーバーライドされているかどうかを確認します。
<cfsetting requestTimeOut = "3600">
最後に、一部の cfscript タグを CFML に置き換えることで回避しなければならないCF の特異な動作の問題があります。requestTimeout
リクエストが cf に渡されると、iis がそのリクエストを処理しなくなったからではありません。アプリケーションプールのタイムアウトを試してみて、エラーをスローできるかどうかを確認してください。