データベースに大きな画像を保存しても意味がないことは明らかです。 これには多くの理由があり、それらのすべては長い間誰にも知られていますが、FileStreamはまだ考慮されていません。 ただし、タスクはしばしば1ページから大量の些細なことを与えることから生じます-たとえば、ブログまたはソーシャルネットワーク上のアバター、サムネイル、フィードのニュースプレビューなど、 グラフィックは比較的簡単ですが、商業的な量です。 問題は、そのような画像がそれぞれ返されると、サーバーへの個別の接続が作成されることです。その結果、1ページを読み込むと、小さなものを返すための数十のリクエストが生成されます。 現在のチャネルでは、これは何もありませんが、ページをレンダリングするときのサーバーリクエストの束は悪いです。
非常に興味深いのは、この些細なポットベリーがすべて1つのストリームで提供されるソリューションです。 したがって、サーバーへのリクエスト数を1桁減らします。これは、DDoS攻撃に対するサイトの抵抗力を高めることを意味します。 快適なボーナスとして-使いやすさの向上：すべての写真がすぐに（「読み込み」の効果なしで）ページに表示され、同時に「穴」なしで表示されます。 外観の前の短い休止は主観的にはカウントされませんが、このような負荷は「高速」に見えます。
このスキームのように見えます。データベース内の画像に対応するIDを持つプレースホルダーは、HTMLファイルのテキストに配置されます。 Javascriptはプレースホルダーを「実行」し、それに応じてサーバーがbase64でエンコードされた文字列の配列を返すXMLHTTP要求文字列を生成します。これは再びJavaScriptがそれぞれのプレースホルダーのsrcに広がります。
その結果、2〜5 kBの個別の写真を数十個受信する代わりに、単一の非同期リクエストで50〜100 kBのJSON文字列を取得します。 つまり、a）メインテキストコンテンツが読み込まれ、レンダリングされた後、およびb）ストリーミングテキストデータの機能により、はるかに高速になります。
作業例 （アバターがネットワークから引き裂かれている）。
コードはページのソースにあります。 PHPのサーブレット（SQLiteで動作）は次のようになります。
<? ob_start(); $dbh = sqlite_open('data/img', 0666, $sqliteerror); $sth = sqlite_query($dbh, "SELECT *, ROWID AS id FROM img WHERE ROWID IN (".trim($_GET['q']).") LIMIT 20"); $res = sqlite_fetch_all($sth, SQLITE_ASSOC); echo json_encode($res); sqlite_close($dbh); ob_end_flush(); ?>
あなたは何と言いますか、完全に馬鹿げた考えですか？ または、自転車を発明しましたか？