(time_starttransfer - time_connect) は間違いなくサーバーがリクエストを処理するのにかかった時間です。
ただし、time_connect と time_pretransfer の違いは何ですか? (@Schwartzie と @Cheeso のコメントに興味をそそられる)
Web でいくつかの curl クエリを調べたところ、等しい場合とそうでない場合があることがわかりました。
次に、HTTPSリクエストのみが異なることがわかりました(少なくとも私はそう信じています)。サーバーがsslレイヤーを復号化するのに時間がかかるため、ターゲットアプリで費やされた時間ではなく、アプリをホストするサーバーで費やされた時間です/サービス。
ssl を復号化する時間 (また、time_connect で指定された接続時間) は time_appconnect であり、それが 0 の場合のみ (https 以外のリクエストの場合など) - time_connect と time_pretransfer は EQUAL であり、それ以外の場合は https リクエストの場合は異なり、https の場合はtime_pretransfer は time_appconnect と等しくなります (time_connect ではありません)。
次の 2 つの例を確認してください。
curl -kso /dev/null -w "time_connect=%{time_connect}, time_appconnect:%{time_appconnect}, time_pretransfer=%{time_pretransfer}\n" http://www.csh.rit.edu
- time_connect=0.128、time_appconnect:0.000、time_pretransfer=0.128
curl -kso /dev/null -w "time_connect=%{time_connect}, time_appconnect:%{time_appconnect}, time_pretransfer=%{time_pretransfer}\n" https://www.csh.rit.edu
- time_connect=0.133、time_appconnect:0.577、time_pretransfer=0.577
そのため、time_pretransfer は、ssl 接続も尊重するため、time_connect と比較して使用する方が正確であると言えます。
これまでのすべてのことを踏まえて、質問に対するより正確な答えを言いたいと思います。
- 「サーバーがリクエストの処理にかかった時間をどのように判断できますか?」
おそらく次のようになります。
- time_starttransfer - time_pretransfer
@Schwartzieがすでに述べたように、その理由を理解したかっただけです。