none
Troubleshooting Connectivity #6 - 接続タイムアウトは悪なのか? 後編 RRS feed

  • 質問

  • (※ 2013/8/29 に Microsoft SQL Server Japan Support Team Blog に公開した情報のアーカイブです。)

    Troubleshooting Connectivity #6 - 接続タイムアウトは悪なのか? 前編

    https://social.technet.microsoft.com/Forums/ja-JP/de53f1df-855b-4e8b-852e-99311eccf15b/troubleshooting-connectivity-6-?forum=jpbidp

    接続タイムアウトの役割とは?


    接続タイムアウトはこの「遅延を許容するか、それともエラーで中断させるか」を判断するための設定値と言えます。


    著しく遅延している状況については障害として詳しく調査する必要があるかもしれませんが、いつもよりちょっとだけ遅いくらいなら、エラーにせずに時間かかったなという程度で済むものもあります。この判断材料として接続タイムアウトを使用してほしいのです。


    したがって、開発者、および、システム提供者の皆様には、システムの利用環境、システムの利用者、システムの要件を加味してた上で、通常時の接続に要する時間の幅をあらかじめ計測するなどにより見積もり、その最長時間よりもどのくらい長くかかったものを障害とするか、という判断をぜひともまず最初に実施ください。


    例えばこんな環境/システムがあったとします。

    • LAN 利用者の通常時の接続完了までの時間: 3秒 ~ 10 秒
    • WAN 利用者の通常時の接続完了までの時間: 20 秒 ~ 40 秒
    • サーバー環境でのフェールオーバーに要する時間: 40 秒 ~ 1分
    • システム要件: フェールオーバーした際にも可能な限りエラーとさせない。

    上記の場合、接続要求が成功するのに 1分以上を要する可能性があるということになりますね。この場合には、接続タイムアウトが 100 秒ではギリギリの可能性がありますので、余裕を持たせて 120 秒、150 秒としてもいいかもしれません。()

    () 実際の対応としては、接続タイムアウトを延ばすだけではなく、それに加えて接続の再試行のロジックを組み入れることが堅牢性に優れたシステムと言えます。


    要件などは様々あり、上記は一例でしかありませんが、考え方の参考になれば幸いです。



    最後に: 接続タイムアウトは悪なのか?


    「接続タイムアウトは悪なのか?」ですが、私の答えは「No」 です。


    前述の通り、接続タイムアウトは利用システム/環境の状況を判断するための材料でしかありません。その環境やシステムに応じて適切に設定している状況下で発生し、その遅延の要因となっているものが想定外の障害であった場合にはじめてそれが悪だといえるのだと思います。


    なお、遅延の要因などを調査する場合には、前述した「Troubleshooting Connectivity #2 - エラー情報からわかる失敗原因」のほか、先に公開している以下のブログを参考に切り分けや情報採取などを実施してみてください。

    Troubleshooting Connectivity #1 - SQL Server への接続

    Troubleshooting Connectivity #4 - 接続エラーの調査方法


    ※今回は接続タイムアウトについて述べていますが、クエリ タイムアウト (もしくはコマンド タイムアウト) も同様です。どのくらいかかったら「そのシステムにおいて」問題があるとみなすのかの基準値として考えて適切な値を設定しましょう。仕組みについては、以下のブログで紹介していますのでご覧ください。

    クエリタイムアウト - その仕組み



    2019年4月4日 10:27
    所有者