だから私はphpで何かに取り組んでおり、base64でエンコードされるSQLデータベースから画像を取得する必要があります。これらの画像を表示する速度は非常に重要であるため、データベース データを画像ファイルに変換してからブラウザにロードするか、生の base64 データをエコーして使用する方が速いかどうかを調べようとしています。
<img src="data:image/jpeg;base64,/9j/4AAQ..." />
これは、FireFox およびその他の Gecko ブラウザでサポートされています。
要約すると、実際の画像ファイルまたはbase64コードを転送する方が速いでしょうか。ajaxを使用して画像をロードする場合、必要なhttpリクエストは少なくなりますか?
画像は合計 100 ピクセル以下です。
さて、私はあなたの誰にも同意しません。より多くの画像をロードしなければならない場合があります。すべてのページに3つの画像が含まれているわけではありません。実際、私はあなたが200以上の画像をロードしなければならないサイトで働いています。非常に負荷の高いサイトで100000人のユーザーが200枚の画像をリクエストするとどうなりますか。サーバーのディスクは、イメージを返し、折りたたむ必要があります。さらに悪いことに、base64を使用するのではなく、サーバーに対して大量のリクエストを行う必要があります。非常に多くのサムネイルについては、データベースに事前に保存されているbase64表現をお勧めします。私はhttp://www.stoimen.com/2009/04/23/when-you-should-use-base64-for-images/で解決策と強力な議論を見つけました。男は本当にその場合であり、いくつかのテストを行いました。感動し、テストもしました。現実はそれが言うようです。1ページに大量の画像が読み込まれる場合、サーバーからの1つの応答が非常に役立ちます。
イメージが変更されない場合、イメージを何度も再生成する必要はありません。仮に、1000 の異なる条件に基づいて 1000 の異なる画像が表示される可能性があるとしても、ディスク上の 1000 の画像の方が優れていると思います。ディスクベースの画像はブラウザによってキャッシュされ、帯域幅などを節約できることを覚えておいてください.
最初の質問に答えるために、96 ppi で 400x300 ピクセルの jpeg 画像を測定するテストを実行しました。
base64ImageData.Length
177732
bitmap.Length
129882
アイコンにbase64画像を1、2回使用しました（10x10ピクセル程度）。
data://IE7 以下では動作しないと思います。
画像が要求されたら、それをファイルシステムに保存してからそれを提供できます。データベース内の画像データが変更された場合は、ファイルを削除してください。img.domain.com などの別のドメインからも配信します。必要でない限り、PHP を起動しなくても、最終更新タグまたは e-tag のすべての利点を Web サーバーから無料で取得できます。
Apache を使用している場合:
# If the file doesn't exist:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^/(image123).jpg$ makeimage.php?image=$1
これは非常に高速で簡単なソリューションです。画像サイズは約 33% 増加しますが、base64 を使用すると、http 要求の数が大幅に減少します。
Google 画像と Yahoo 画像は base64 を使用し、画像をインラインで提供しています。ソースコードを確認すると、それが表示されます。
もちろん、このアプローチには欠点もありますが、コストを上回る利点があると私は信じています。私が見つけた短所は、遅いデバイスにあります。たとえば、iPhone 3GS では、画像はサーバーから gzip で圧縮され、ブラウザで圧縮解除する必要があるため、Google 画像によって提供される画像のレンダリングが非常に遅くなります。そのため、顧客のデバイスが遅い場合、画像をレンダリングするときに少し苦労します。
通常、base64 エンコーディングを使用すると、バイト サイズが約 1/3 増加します。そのため、データベースからサーバーに 1/3 バイトを移動し、その余分な同じ 1/3 バイトをネットワーク経由でブラウザーに移動する必要があります。
もちろん、画像のサイズが大きくなるにつれて、前述のオーバーヘッドもそれに比例して増加します。
そうは言っても、ファイルをデータベース内のバイト表現に変更して送信するのは良い考えだと思います。
OP質問に答える。静的ファイルとして、ディスク経由で Web サーバー経由で直接。わずか 100 ピクセルで、Web サーバーによるメモリ内キャッシュに最適です。そこには、ほぼすべてのWebサーバーに関する情報、キャッシュ戦略、構成、ハウツーがたくさんあります.
事実 - ユーザー エクスペリエンス (参照するイメージ速度) の点で最良のオプションは、CDN 対応のオブジェクト ストアを使用することです。限目。
静的ストレージの選択としての「DB」は、すべてのオーバーヘッド処理、DB への負担、財政的、および技術的負債の観点から、単純に費用がかかります。
いくつかの答えから、いくつかのこと
Google 画像と Yahoo 画像は base64 を使用し、画像をインラインで提供しています。ソースコードを確認すると、それが表示されます。
いいえ、絶対にありません。画像は主に静的ファイル「Web サーバー」から提供されます。
コンパクト - 単一のファイルがあります。また、ファイルが圧縮されている場合、base64 イメージは通常のイメージのサイズにほぼ圧縮されます。
実際には、まったく利点がなく、さらに圧縮に必要な処理はありますか?
ページは単一のリクエストで取得されます。繰り返しになりますが、単一の大きな負荷ではなく、複数の並列リクエストです。
非常に負荷の高いサイトで 100000 人のユーザーが 200 枚の画像を要求するとどうなるでしょうか。画像を返すサーバーのディスクは崩壊するはずです。それでも同じ量のデータを送信しますが、接続時間が長くなり、データベースに負荷がかかります. 第 2 に、100000 の同時接続を持つミル サイトの実行のオッズです... たとえそうであったとしても、これをすべて単一のサーバーで実行している場合、あなたは愚かな管理者です。
イメージ (バイナリ BLOB または Base64) を DB に格納することで、DB に膨大なオーバーヘッドが追加されます。大量のRAMがあるか、DBを介したクエリがとにかくディスクから出てきます。そして、そのような無制限の RAM を DID で使用している場合は、Ramdisk からビン イメージを提供します。理想的には、代替の専用の軽量 Web サーバー静的ファイルと最適化されたサブドメインで構成されたキャッシングを介して、可能な限り最速で最も軽い負荷になります!
前向きな計画？これまでのところスケールアップしかできず、DB のスケーリングにはコストがかかります (比較的言えば)。繰り返しますが、あなたが言うディスクは「sp
このような場合、100,000 人の同時ユーザーに数百の画像を提供している場合、画像の提供は CDN オブジェクト ストアのドメインにする必要があります。
最速の速度が必要な場合は、アップロード/変更時にディスクに書き込み、Web サーバーに静的ファイルを提供させる必要があります。Rojoca の提案も、php の呼び出しを最小限に抑えるため、優れています。別のドメインからサービスを提供することの追加の利点は、(ほとんどの) ブラウザーが要求を並行して発行することです。
それを除いて、データをクエリするときは、最後に変更されたかどうかを確認してから、ディスクに書き込み、そこから提供します。不必要にデータを転送しないように、If-Modified-Since ヘッダーを尊重するようにしてください。
ディスクやその他のキャッシュに書き込むことができない場合は、バイナリ データとしてデータベースに格納し、ストリーミングするのが最も高速です。その時点で、バッファサイズを調整すると役立ちます。
