web-dev-qa-db-ja.com

サーバーの「待機」時間を短縮するにはどうすればよいですか?

サイトの速度を最適化しようとしています。 pingdom.com のすばらしいツールを使用しています。現在、ページの読み込みにかかる時間の50%以上は、下のスクリーンショットに示すように「待機」時間です。これを減らすにはどうすればよいですか?また、この数字はどのくらい典型的ですか?これに関するベンチマークはありますか?ありがとう!

high server wait time

EDIT:OK ..いくつかのことを明確にしましょう。サーバー側のスクリプトやデータベース呼び出しは実行されていません。 HTML、CSS、JS、および画像のみ。並列ダウンロードを取得するために、jsをbodyタグの最後にプッシュするなどの処理を既に実行しました。 main.htmlとtemplates.htmlがjs.jsのダウンロード後に同期的に実行されることで、全体の待機時間に追加されていることを認識していますが、それは問題ではありません。各リクエストに「待機」時間がどれだけあるかに驚いています。サーバー距離はこれに影響しますか?共有サーバー上にある場合、待機時間に影響しますか?これらの問題を解決するための低品質の果物はありますか?

enter image description here

34
alnafie

Apacheの場合の最も一般的な理由は、DNSリバースルックアップの使用です。これは、リクエストを行うたびに、サーバーがマシンの名前を把握しようとすることを意味します。これには数秒かかる場合がありますが、これは、待機時間が長く、ロードが非常に速い理由を説明しています。これは帯域幅に関する問題ではないためです。

これに対する明白な解決策は、/ etc/httpd/conf/httpd.confでhostnamelookupを無効にすることです

HostnameLookups Off

しかし...これは通常十分ではありません。実際には、多くの場合、ホスト名のルックアップを無効にした場合でも、Apacheはまだリバースルックアップを行うため、Apache構成の各行を注意深く調べる必要があります。特に、これの最も一般的な理由の1つはLOGSです。多くのRed Hat-CentOSインストールのデフォルトでは、ログ形式には「ホスト名」を表す%hが含まれており、Apacheが逆引き参照を行う必要があります。これはここで見ることができます:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common

この問題を解決するには、%aの%hを変更する必要があります。

53
Mickle Foretic

ページが待機しているサーバーリクエストが複数ある場合は、それらのサーバーリクエストが非同期で並行して送信されるようにして、シリアル化することができます。

複数のリクエストをフェッチする最も遅い方法は、1つのリクエストを送信し、そのレスポンスを待機し、次のリクエストを送信し、そのレスポンスを待機するなどです。通常、すべてのリクエストを非同期で送信し、到着したすべてのレスポンスを処理する方がはるかに高速です。これにより、すべてのリクエストの累積待機時間ではなく、単一のリクエストの合計待機時間が最長待機時間に短縮されます。

単一のリクエストのみを作成している場合、クライアント側でできることは、ページの他の部分ができるように、リクエストがページ読み込みシーケンスのできるだけ早い時点でサーバーに送信されるようにすることですリクエストの処理中にビジネスを行っているため、最初のリクエストがより早く開始されます(したがって、より早く終了します)。

2
jfriend00

最初のバイトまでの時間 とも呼ばれる待機時間は、接続が開始されてからサーバーが最初のバイトを送信するのにかかる時間です。これが高い場合、サーバーはページを送信する前にレンダリングするために多くの作業を行わなければならないことを意味します。あなたのサイトがページをレンダリングするために何をしているかについての詳細情報が必要です。

1
ddlshack

TTFBは、ブラウザとサーバー間の「物理的な」距離に直接影響されます。 CDNプロキシは、上記の距離を短縮する最良の方法です。これは、ネイティブのキャッシング機能と相まって、最も近いPOP(配置のポイント)の場所からキャッシュされたオブジェクトをロードすることにより、迅速な応答を提供するのに役立ちます。

効果は、ユーザーの地理的位置とCDNの広がりに依存します。それでも、 大幅な改善 、50%-70%以上が期待できます。

経験から言えば、コンテンツの90%がキャッシュされ、地球の反対側から別の大陸に配置されたプロキシから直接配信されるケースを見ました。

0
Igal Zeifman