キャッシュされ、PHPで生成されたサムネイルの読み込みが遅い

質問パート A▉（100バウンティ、受賞）
主な質問は、このサイトをより速くロードする方法です。まず、これらの滝を読む必要がありました。ウォーターフォールの読み出し分析に関するご提案をありがとうございます。ここに示されているさまざまなウォーターフォールグラフから明らかなのは、主なボトルネックであるPHPによって生成されたサムネイルです。Davidの助言による、CDNからのプロトコルのないjqueryの読み込みは、サイトの全体的なボトルネックに答えずにサイト全体を3％だけ高速化しましたが、私の賞金を獲得しました。私の質問を明確にするための時間、そしてもう一つの賞金：

質問パート B▉（100バウンティ、受賞）
新しい焦点は、6つのjpg画像が持つ問題を解決することでした。これにより、読み込み遅延のほとんどが発生しています。これらの6つの画像は、PHPで生成されたサムネイルで、サイズはわずか3〜5 kbですが、読み込みが非常に遅くなります。さまざまなグラフの「最初のバイトまでの時間」に注目してください。問題は未解決のままでしたが、報奨金がジェームズに送られました。ジェームズは、RedBotが下線を引いたヘッダーエラーを修正しました：「If-Modified-Since条件付きリクエストがコンテンツ全体を変更せずに返しました。」。

質問パート C▉（私の最後の報奨金：250ポイント）
残念ながら、REdbot.orgヘッダーエラーでさえ修正された後、PHPで生成された画像による遅延はそのまま残りました。これらの小さなちっぽけな3〜5Kbのサムネイルは一体何を考えているのですか？そのすべてのヘッダー情報は、ロケットを月に送り返したりすることができます。すでに7か月間このボトルネックの問題に悩まされているため、このボトルネックに関する提案は高く評価され、可能な限りの回答として扱われます。よろしくお願いします。

[私のサイトの背景情報：CSSが一番上にあります。下部のJS（Jquery、JQuery UI、購入したメニューawm / menu.jsエンジン、タブjsエンジン、ビデオswfobject.js）2番目の画像の黒い線は、何をロードするかを示しています。怒っているロボットは私のペット「ZAM」です。彼は無害で、しばしば幸せです。]

負荷の滝：時系列 | http://webpagetest.org

グループ化された並列ドメイン | http://webpagetest.org

Site-Perfウォーターフォール | http://site-perf.com

Pingdom Tools Waterfall | http://tools.pingdom.com

GTmetrixウォーターフォール | http://gtmetrix.com

まず、これらの複数のドメインを使用するには、いくつかのDNSルックアップが必要です。リクエストを分散させるのではなく、それらの画像の多くをスプライトに組み合わせた方がよいでしょう。

次に、ページをロードすると、all.jsのほとんどのブロッキング（約1.25秒）が表示されます。私はそれが（古いバージョンの）jQueryで始まるのがわかります。読み込み時間を短縮するだけでなく、それに対するHTTPリクエストを完全に回避するために、Google CDNからそれを参照する必要があります。

具体的には、最新のjQueryおよびjQuery UIライブラリをこれらのURLで参照できます（私がを省略した理由に興味がある場合は、この投稿を参照してくださいhttp:）。

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

//ajax.googleapis.com/ajax/libs/jqueryui/1.8.9/jquery-ui.min.js

デフォルトのjQuery UIテーマの1つを使用している場合は、そのCSSと画像をGoogle CDNからプルすることもできます。

jQueryホスティングを最適化したら、組み合わせて1つのファイルにする必要もawmlib2.jsありtooltiplib.jsます。

これらの問題に対処すると、大幅な改善が見られます。

数日前に同様の問題が発生し、head.jsが見つかりました。これは、すべてのJSファイルを並列にロードできるJavascriptプラグインです。お役に立てば幸いです。

私は専門家とはかけ離れていますが...

これに関して、「If-Modified-Since条件付きリクエストがコンテンツ全体を変更せずに返しました。」と私のコメント。

サムネイルの生成に使用されるコードは、以下をチェックする必要があります。

1. サムネイルのキャッシュバージョンはありますか。
2. キャッシュされたバージョンは、元のイメージよりも新しいですか。

これらのいずれかがfalseの場合、サムネイルは生成され、何が返されます。両方が真の場合、次のチェックを行う必要があります。

1. HTTP_IF_MODIFIED_SINCEヘッダーはありますか
2. キャッシュされたバージョンの最終更新時刻はHTTP_IF_MODIFIED_SINCEと同じですか

これらのいずれかがfalseの場合、キャッシュされたサムネイルが返されます。

これらの両方が真の場合、304 HTTPステータスが返されます。必要かどうかはわかりませんが、個人的には、Cache-Control、Expires、Last-Modifiedヘッダーを304とともに返します。

GZippingに関しては、GZipの画像は必要ないので、コメントのその部分は無視するように言われました。

編集：投稿への追加に気づきませんでした。

session_cache_limiter('public');
header("Content-type: " . $this->_mime);
header("Expires: " . gmdate("D, d M Y H:i:s", time() + 2419200) . " GMT");
// I'm sure Last-Modified should be a static value. not dynamic as you have it here.
header("Last-Modified: " . gmdate("D, d M Y H:i:s",time() - 404800000) . " GMT");

また、コードでHTTP_IF_MODIFIED_SINCEヘッダーを確認してそれに対応する必要があることも確信しています。これらのヘッダーと.htaccessファイルを設定するだけでは、必要な結果が得られません。

私はあなたがこのようなものが必要だと思います：

$date = 'D, d M Y H:i:s T'; // DATE_RFC850
$modified = filemtime($filename);
$expires = strtotime('1 year'); // 1 Year

header(sprintf('Cache-Control: %s, max-age=%s', 'public', $expires - time()));
header(sprintf('Expires: %s', date($date, $expires)));
header(sprintf('Last-Modified: %s', date($date, $modified)));
header(sprintf('Content-Type: %s', $mime));

if(isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])) {
    if(strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) === $modified) {
        header('HTTP/1.1 304 Not Modified', true, 304);
        // Should have been an exit not a return. After sending the not modified http
        // code, the script should end and return no content.
        exit();
    }
}
// Render image data

うわー、その画像を使用して説明するのは難しいです。しかし、ここでは、いくつかの試み：

• ファイル33から36は、それらがswf内で動的にロードされ、追加のコンテンツをロードする前に、swf（25）が最初に完全にロードされるため、ロードが遅くなります。
• ファイル20と21は、おそらく all.js（11）によって読み込まれる（コードがわからないため、わかりません）ライブラリですが、11が実行されると、ページ全体（およびアセット）を待機しますロードする（domreadyに変更する必要があります）
• ファイル22〜32は、これらが完全にロードされた後、これら2つのライブラリによってロードされます。

この種の分析には多くのA / Bテストが必要なため、単純な推測です。.chドメインに到達するのは難しいようです（最初のバイトが到着する前に長い緑色の帯）。

これは、.ch Webサイトが十分にホストされていないか、ISPがそれらに適切なルートを持っていないことを意味します。

ダイアグラムを考えると、これはパフォーマンスの大きな打撃を説明することができます。

余談ですが、このクールなツールcuzillionは、リソースのロードの順序に応じて物事を整理するのに役立ちます。

サイト/ページでY！SlowテストとPage Speedテストを実行し、ガイドラインに従ってパフォーマンスのボトルネックを解決してください。Y！SlowまたはPage Speedのスコアが高くなると、パフォーマンスが大幅に向上するはずです。

これらのテストは何が間違っているか、何を変更すべきかを教えてくれます。

あなたのPHPスクリプトは、ページが読み込まれるたびにサムネイルを生成していますか？まず、サムネイル化されている画像がそれほど頻繁に変更されない場合は、ページが読み込まれるたびに画像を解析する必要がないようにキャッシュを設定できますか？次に、PHPスクリプトimagecopyresampled()はサムネイルを作成するようなものを使用していますか？これは重要なダウンサンプルであり、PHPスクリプトは処理が完了するまで何も返しません。imagecopymerged()代わりにを使用すると、イメージの品質が低下しますが、プロセスが高速化します。そして、どのくらいの削減を行っていますか？これらのサムネイルは、元の画像の5％のサイズですか、それとも50％ですか？元の画像のサイズが大きいと、PHPスクリプトが元の画像を縮小して小さなサムネイルを出力する前にメモリに取得する必要があるため、速度が低下する可能性があります。

私はあなたのウェブサイトのURLを見つけ、ホームページから個々のjpgファイルをチェックしました。読み込み時間は妥当な時間（161ミリ秒）ですが、126ミリ秒待機しています。

最後に変更されたヘッダーはすべて、土曜日、2011年1月1日12:00:00 GMTに設定されています。これは、実際の生成日には「丸すぎ」に見えます;-)

Cache-controlは "public、max-age = 14515200"であるため、168日後に任意の最終変更ヘッダーが問題を引き起こす可能性があります。

とにかく、これが遅延の本当の理由ではありません。

サムネイルが既に存在する場合のサムネイルジェネレータの動作と、画像のチェックと配信に多くの時間を費やす可能性があるものを確認する必要があります。

xdebugをインストールできますをしてスクリプトのプロファイルを作成し、ボトルネックの場所を確認ます。

多分すべてがフレームワークを使用するか、何もせずにいくつかのデータベースに接続します。一部のサーバーでmysql_connect（）が非常に遅いことを確認しました。ほとんどの場合、サーバーがソケットではなくTCPを使用して接続していたため、DNSの問題が発生することがあります。

ここに有料のジェネレーターを投稿できないとのことですが、問題が多すぎると思います...

本当に正当な理由がない場合（通常はありません）、画像でPHPインタープリターを呼び出すことはできません。

ファイルシステムでイメージが見つかった場合、イメージを直接処理するWebサーバーの書き換えルールを作成します。そうでない場合は、PHPスクリプトにリダイレクトして画像を生成します。画像を編集するときは、画像のファイル名を変更して、キャッシュされたバージョンを持つユーザーが新しく編集された画像を取得するように強制します。

少なくとも機能しない場合は、画像の作成およびチェック方法とは何の関係もありません。

PHPのセッションデータの使用状況を調査します。たぶん（たぶん）、画像生成PHPスクリプトがセッションデータのロックを取得するのを待っています。このデータは、まだレンダリングされているメインページまたは他の画像レンダリングスクリプトによってロックされています。これは、ブラウザーがサーバーを待機しているため、JavaScript /ブラウザーのすべての最適化をほとんど意味のないものにします。

PHPは、セッション処理が開始された瞬間からスクリプトが終了する瞬間まで、またはsession_write_close（）が呼び出されたときに、実行中のすべてのスクリプトのセッションデータをロックします。これは事実上物事をシリアライズします。セッションのPHPページ、特にこのようなコメントを確認してください。

私はあなたのコードを見ていないので、これは大まかな推測ですが、セッションがここで役割を果たすと思われます。以下は、PHP Manual Manualのエントリsession_write_close()です。

セッションデータは通常、session_write_close（）を呼び出さなくてもスクリプトが終了した後に保存されますが、同時書き込みを防ぐためにセッションデータがロックされるため、いつでも1つのスクリプトのみがセッションを操作できます。フレームセットをセッションと一緒に使用すると、このロックによりフレームが1つずつ読み込まれます。セッション変数へのすべての変更が完了したらすぐにセッションを終了することにより、すべてのフレームのロードに必要な時間を短縮できます。

私が言ったように、私はあなたのコードが何をしているのかわかりませんが、それらのグラフは奇妙に怪しいようです。マルチパートファイルサービス機能をコーディングしたときにも同様の問題が発生し、同じ問題が発生しました。大きなファイルを提供する場合、ダウンロードが完了するまで、マルチパート機能を動作させることも、別のページを開くこともできませんでした。呼び出しsession_write_close()は私の両方の問題を修正しました。

PHPで生成されたサムネイルを通常の画像に置き換えて、違いがあるかどうかを確認しましたか？問題は、周りにある可能性があります-サーバーの呼び出しごとにサムネイルの再生成につながるphpコードのバグ-クロックの問題に関連するコードの遅延（sleep（）？）-非常に悪い競合状態を引き起こすハードドライブの問題すべてのサムネイルが同時にロード/生成されるためです。

そのサムネイル生成スクリプトを使用する代わりに、TinySRCを指定する必要があると思いますでクラウドホスティングされた高速なサムネイル生成を試してみる。それは非常にシンプルで使いやすいAPIを備えており、次のように使用できます：-

http://i.tinysrc.mobi/ [高さ] / [幅] /http://domain.tld/path_to_img.jpg

[幅]（オプション）：-これはピクセル単位の幅です（アダプティブサイズまたはファミリーサイズをオーバーライドします）。接頭辞が「-」または「x」の場合、決定されたサイズから差し引かれるか、決定されたサイズの割合に縮小されます。

[高さ]（オプション）：-幅も存在する場合、これはピクセル単位の高さです。また、アダプティブサイズまたはファミリーサイズをオーバーライドし、先頭に「-」または「x」を付けることができます。

ここで APIの概要を確認できます

よくある質問

tinySrcにかかる費用は？

何もない。

tinySrcの使用をいつ開始できますか？

今。

サービスはどの程度信頼できますか？

tinySrcサービスについては保証しません。ただし、主要な分散型クラウドインフラストラクチャ上で実行されるため、世界中で高い可用性を提供します。すべてのニーズに十分対応できるはずです。

どれくらい速いですか？

tinySrcは、サイズ変更された画像をメモリとデータストアに最大24時間キャッシュし、毎回元の画像を取得しません。これにより、ユーザーの観点から見ると、サービスは非常に高速になります。（そして素晴らしい副作用としてサーバーの負荷を減らします。）

幸運を。ただの提案ですが、コードは表示されません：p

一部のブラウザはドメインごとに2つの並行ダウンロードのみをダウンロードするため、2〜3つの異なるホスト名でリクエストを分割するために追加のドメインを追加できませんでした。例1.imagecdn.com 2.imagecdn.com

まず、If-Modified-SinceJamesが言ったように、リクエストなどを適切に処理する必要があります。そのエラーは、「そのイメージが前回から変更されているかどうかをサーバーに尋ねると、単純なyes / noではなく、イメージ全体を送信します」と述べています。

接続と最初のバイトの間の時間は、通常、PHPスクリプトの実行にかかる時間です。そのスクリプトが実行を開始すると、何かが起こっていることは明らかです。

1. プロファイリングを検討しましたか？いくつか問題があるかもしれません。
2. 上記の問題と相まって、スクリプトは必要以上に何度も実行されている可能性があります。理想的には、元の画像が変更された場合にのみサムを生成し、他のすべてのリクエストに対してキャッシュされたサムを送信する必要があります。スクリプトが不必要に画像を生成していることを確認しましたか（リクエストごとなど）？

アプリケーションを介して適切なヘッダーを生成するのは少し難しいので、サーバーによって上書きされる可能性があります。また、キャッシュを使用しないリクエストヘッダーを送信するとサムネイルジェネレーターが継続的に実行される（そして負荷が増える）ため、不正使用にさらされます。したがって、可能であれば、生成されたサムを保存し、保存した画像をページから直接呼び出して、からヘッダーを管理してください.htaccess。この場合、.htaccessサーバーが適切に構成されていれば、何も必要ありません。

これら以外に、リソースをCookieを使用しないサブドメインに分割するなど、ウェブサイトを正しい方法で実行する方法について、この全体的なすばらしいSOの質問のパフォーマンス部分から明るい最適化のアイデアを適用できます。ただし、いずれにしても、3k画像読み込みに1秒もかかりません。これは、グラフの他のアイテムと比較すると明らかです。最適化する前に問題を特定する必要があります。

画像やスタイルシートなどの静的データを提供するために、NGINXウェブサーバーの下にいくつかのサブドメインを設定しようとしましたか？このトピックには、役立つ情報がすでに記載されています。

遅延したサムネイルについては、サムネイル生成スクリプトのheader（）への最後の呼び出しの直後にflush（）への呼び出しを配置し​​てみてください。完了したら、ウォーターフォールグラフを再生成し、遅延がヘッダーではなく本文にあるかどうかを確認します。もしそうなら、画像データを生成および/または出力するロジックを詳しく調べる必要があります。

サムネイルを処理するスクリプトは、何らかのキャッシュを使用して、提供している画像に対して実行するアクションが絶対に必要な場合にのみ実行されるようにする必要があります。いくつかの高価な操作はあなたが遅延され、サムネイル果たすたびに行われているように見えます任意のスクリプトから（ヘッダを含む）を出力します。

遅い問題の大半は、TTFB（最初のバイトまでの時間）が高すぎることです。これは、サーバーの構成ファイル、コード、基盤となるハードウェアに精通することなく取り組むのが難しいものですが、すべてのリクエストで蔓延していることがわかります。緑のバーが多すぎ（不良）、青のバーが少なかった（良い）。フロントエンドの最適化をやめた方がいいかもしれません。その分野で多くのことを行ってきたと思います。「エンドユーザーの応答時間の80％〜90％がフロントエンドで費やされている」という格言にもかかわらず、私はあなたの反応がバックエンドで発生していると思います。

TTFBは、バックエンドスタッフ、サーバースタッフ、出力前の前処理とハンドシェイクです。

コード実行の時間を計って、遅いデータベースクエリのような遅いものを見つけ、時間のかかる関数/メソッドに出入りして遅い関数を見つけます。PHPを使用している場合は、Firephpを試してください。起動または初期化中に、セッション情報の取得や認証の確認など、1つまたは2つの遅いクエリが実行される場合があります。クエリを最適化すると、パフォーマンスが向上します。php prependまたはspl autoloadを使用してコードが実行される場合があるため、すべてで実行されます。また、apache confの構成が不適切な場合や、日を節約するための調整が必要な場合もあります。

非効率的なループを探します。キャッシュのフェッチ呼び出しが遅いか、ディスクドライブの障害またはディスク領域の使用率が高いためにI / O操作が遅いかを確認します。メモリの使用状況と、何がどこで使用されているかを確認します。同じ場所ではなく、世界中のさまざまな場所からの最初のビューのみを使用して、単一の画像またはファイルに対して10回の実行のwebpagetest繰り返しテストを実行します。そして、アクセスログとエラーログを読んでください。あまりに多くの開発者がそれらを無視し、出力された画面上のエラーのみに依存しています。あなたのウェブホストがサポートを持っているなら、彼らに助けを求めてください。とにかく彼らが丁寧に助けを求めないなら、それは害にはなりません。

DNSプリフェッチを試して、多くのドメインとリソースに対抗できます。http：//html5boilerplate.com/docs/DNS-Prefetching/

サーバーはあなた自身の良い/まともなサーバーですか？時には、より良いサーバーが多くの問題を解決することができます。私は、「ハードウェアが安く、プログラマーが高価である」という考え方を愛しています。または、maxcdnやcloudflareなどのCDNを使用します。

幸運を！

（私はこれらの会社で働いていません。また、上記のcloudflareリンクはTTFBはそれほど重要ではないと主張します。私はそこにそれを投げ入れて、あなたが別の見解を得られるようにします。）

申し訳ありませんが、提供するデータはほとんどありません。そして、あなたはすでにいくつかの良い提案を持っていました。

それらの画像をどのように提供していますか？それらをPHP経由でストリーミングしている場合、たとえそれらがすでに生成されていても、非常に悪いことをしています。

PHPで画像をストリーミングしないでください。どのように使用しても、サーバーの速度が低下します。

それらを、わかりやすいURIを使用して、アクセス可能なフォルダーに配置します。次に、実際のURIを使用して直接呼び出します。オンザフライ生成が必要な場合は、リクエスト画像が欠落している場合にのみ、ジェネレーターのphp-scriptにリダイレクトする.htaccessをimagesディレクトリに配置する必要があります。（これは、要求時キャッシュ戦略と呼ばれます）。

これを行うと、phpセッション、ブラウザプロキシ、キャッシング、ETAGSなど、すべて一度に修正されます。

WP-Supercacheは、適切に構成されている場合、この戦略を使用します。

私はこれを少し前に書きました（http://code.google.com/p/cache-on-request/source/detail?r=8）、最後のリビジョンは壊れていますが、8以下でうまくいくと思います。例として、.htaccessを例として取り上げます（ただし、.htaccessを構成する方法は、以前よりも優れています）。

この戦略については、このブログ投稿（http://www.stefanoforenza.com/need-for-cache/）で説明しました。それはおそらくひどく書かれていますが、物事を明確にするのに役立つかもしれません。

参考資料：http : //meta.wikimedia.org/wiki/404_handler_caching