私は画像共有サイトを構築していますが、PHPを使用してその場で画像のサイズを変更し、サイズ変更した画像を保存することの長所と短所を知りたいと思います。
どちらが速いですか？
どちらがより信頼できますか？
速度とパフォーマンスの2つの方法のギャップはどのくらいですか？
ビューなどの統計情報のために画像がPHPスクリプトを通過する方法、またはホットリンクが許可されている場合などに注意してください。サイズ変更された画像を保存することを選択した場合、画像への直接リンクにはなりません。
この件に関するコメントや役立つリンクをいただければ幸いです。
これは絶対に比較にならない問題です。
実際、その場で画像のサイズを変更することは、自分のサーバーで DoS 攻撃を実行するようなものです。1 つの通常の画像のサイズ変更には、php スクリプトへの通常の 1 つの要求を処理するよりも多くの CPU と RAM が必要です。それはすでにパフォーマンスに大きな影響を与えています。しかし、通常のサムネイルは単独で表示されるのではなく、数で表示されます。そのため、ギャラリー ページを 1 つだけ表示している間に、何十もの負荷の高いプロセスが作成され、サーバーの負荷が 10 倍以上増加します。
私の言葉を証明するための簡単で汚いテスト: 比較的小さい 1,3 メガピクセルの画像のサイズを変更してみましょう
$ /usr/bin/time --format="%MK mem %Es CPU time" /usr/bin/convert angry_birds_1280x800.jpg -resize 100x100 thumb.jpg
10324K mem 0:00.10s CPU time
0.1 秒かかったので、10 個の画像プレビューを表示すると、CPU 時間が丸々 1 秒消費されます。適切に記述された PHP ギャラリー ページは約 0.01 秒かかります。そのため、その場でサイズを変更すると、サーバーの負荷が 100 倍になります。
記憶も同じ。各サイズ変更プロセスは、100M の合計で (100k の画像ファイルのサイズを変更するために) 10M 以上のメモリを消費します。PHP スクリプトの通常のメモリ制限はわずか 8M ですが、これに達することはめったにありません。
それが現実の数字です。
この問題に関連して、ちょっと面白いことがあります:
まったく同じ PHP ユーザーが、同時に1000000 の CPU サイクルを簡単に捨てて、1 つまたは 2 つの CPU サイクルを節約することに信じられないほど嫉妬しています! これはスピーチの図ではありません。ここに私が話していることの例があります:誰かから
の同様の質問で、定数、変数、または変数配列間の速度の違いと同じくらい無視できるほど大きな懸念があります。そして、そのような災害だけでは不十分であるかのように、最近、許可されたメモリサイズが使い果たされる問題に遭遇した人。
このサイトにはたくさんの質問と回答があり、あらゆる操作のナノ秒の速度の違いについて議論し、無尽蔵の尊厳で答え、数百万回の反復テストを実行して、それぞれ数 CPU サイクルのワンショット操作間の違いがまったく無視できることを示しています。
同時に、このような質問があります - 2 つのアプローチ間のパフォーマンスの面での比較にならない巨大な違いについて、著者には単に等しいように見えます。
それが、平均的な PHP ユーザーとこのサイトの問題です。
前者には、実物と微視的な物を区別する手段がありません。
しかし、後者には質問の健全性チェックのメカニズムがありません.2つの質問が互いに矛盾していても（そして両方とも常識に反していても）、全員が同じ熱意で答えました。
動的なサイズ変更は、画像の初期サイズによっては (時間的に) コストのかかる手順になる可能性があります。私は実稼働システムでそれを行いましたが、選択できる場合は、ディスクへのキャッシュを強く好みます。結局のところ、ディスク容量は安価であり、ロード時間は Web のすべてです。サムネイルを特定のサイズで単純にキャッシュし、他の場所で動的にサイズ変更を行うだけでも、ギャラリー スタイルの画像リストの読み込み時間を大幅に短縮できます。
これは時期尚早の最適化のように聞こえます。あなたのサイトに何人のユーザーがいて、サーバーがどれだけの計算量を持っているか知っていますか? パフォーマンスが問題になるまでは、最も単純な (メンテナンスに関する) オプション、つまりオンザフライでサイズ変更を行い、そこから何をすべきかを考えます。
再スケーリングされた画像が繰り返しヒットする可能性がある場合は、何らかのサーバー側のキャッシュを実装することをお勧めしますが、明示的な事前レンダリングまで拡張する必要はないと思います。
画像をキャッシュし、その場でサイズを変更しないことを強くお勧めします。
画像のサイズ変更は、CPU を集中的に使用し、サーバーのメモリを消費します。
その場でスケーリングする画像のギャラリーがある場合、元のファイルサイズにもよりますが、ページは画像をゆっくりと読み込みます。たとえば、3 ～ 10 秒ほどかかります。
サイズを変更する場合、メモリのピクセルあたり約 3 バイトかかります。したがって、1000x1000 の画像のサイズを変更すると、約 3MB のメモリが必要になります。Web ページの 1 つにこれらのオンザフライのサイズ変更画像が多数 (たとえば 20 個) ある場合、サーバーの RAM が約 60MB 必要になります。ほとんどのクライアントは一度に 4 つの画像しか要求しないため、そうではないかもしれませんが、12MB はページロードに対して依然として大量です。ソース画像が 100x100 ピクセル未満の場合にのみ、オンザフライでスケーリングします。
ヒント: サムのスケーリングと保存に最適なライブラリはPhpThumb です。