pingから取得したデータ：往復ですか、それとも片道ですか？

2つのサーバーがあり、それぞれ2つの異なる場所にあります。一方のアプリケーションをホストし、もう一方のデータベースサーバーをホストする必要があります。

アプリサーバーから、データベースサーバーにpingを実行すると、平均で約30ミリ秒かかります。

私の質問は：

When I query the database from the app;

取るつもりですか 30 ms + database_server_query_run_time

または;

+ 30msかかりますか30 ms + database_server_query_run_time

これを理解してください。

networking ping latency

— フィル
ソース

回答:

通常、これらの2つのオプションよりも時間がかかります。

Pingは、クライアントからサーバーまでの時間だけを測定し、再び戻します（rtt-往復時間）

通常、データベースはTCPを使用するため、最初にSYNパケットを送信してTCPハンドシェイクを開始する必要があります（たとえば15ms * + cpu時間を単純化するために、受信してSYN / ACK（15ms + cpu時間）を受信し、ACKとリクエスト（少なくとも15ミリ秒+ CPU時間）、次にDBがクエリを処理する時間、次にデータを取得する時間（15ミリ秒+ CPU）、さらにもう少し確認して接続を閉じます。

もちろん、これはデータベースへの認証（ユーザー名/パスワード）をカウントせず、暗号化（sslハンドシェイク/ DHまたは必要なもの）をカウントしません。

*往復時間の半分。往復のルートが対称的であると仮定します（到着までの時間の半分、到着までの時間の半分... ping応答のCPU処理時間は非常に短いです）

— ムラーズ
ソース

3方向ハンドシェイクの問題は、永続的なTCPセッションで発生する可能性があります。

— ミシェルニック

@Michuelnik、詳しく説明してもらえますか？私はこのこと全体を理解し、DBを照会するための待ち時間を最小限に抑えるための最良の方法を見つけたいと思っています。

— フィル

残念なことに、ほとんどのソフトウェア（少なくともWebアプリ）はこれをサポートしていません：/しかし、アイデアは、DBへの接続を（一度）確立し、接続を実行（開いたまま）し、クエリの送信/応答の取得を続けることです。常時接続を開きます。これにより、毎回tcpハンドシェイク、認証などの必要がなくなります。

— mulaz

mulaz、説明してくれてありがとう。Pythonで作業するので、それがどうなるかを確認します。;

— フィル

リクエストとリプライのサイズを忘れないでください。たとえば、1MB /秒のリンクでは、100KBのペイロードの転送にさらに100msかかります。

— ダスティンボズウェル14年

ping時間は往復です。あなたがそれについて考える場合-それはどのように一方向の時間を測定できますか？そのため、30ミリ秒とクエリ時間を要します。

— デビッド・シュワルツ
ソース

おそらく、30秒+クエリ時間よりも少し長くかかると付け加えます。pingはICMPであり、あなたのDB接続がTCPである、あなたも同様にそこにセットアップ/ハンドシェイク、およびDB接続の開始などがありますので、

— ドーン

@Doon：永続的なTCP /データベース接続により「回避」される可能性がある

— -Michuelnik

@Michuelnik、永続的なDB接続がここに行く方法だと思いますか？他の問題が発生しますか？

— フィル

@michuelnik、もちろん。RTT + Queryほど簡単ではないことを指摘しただけです。また、待ち時間などによるセッションごとの最大速度の制限もあります。）

— Doon

@philほとんどの場合、複数のクエリを実行する場合、永続的なDB接続が有益です。クエリが/ sporadicに分散している場合、リソースを不必要に拘束しますが、クエリが常に発生している場合などは、各リクエストで新しい接続を開くのではなく、既存の接続を再利用することで些細なオーバーヘッドを節約します。

— ドゥーン