6つの異なるパラメーターを使用して画像を生成するWebサービスがあります。プロセスは1秒続きます。ImageCreateFromPNG、ImageCopy、ImageJPEGの各関数を使用しています。これで、速度を上げたいと思います。アイデアは、サーバー上ですでに生成されたイメージを保存し、6つのパラメーターを持つ名前を使用して、それらがすでに存在する場合はそれらを使用することです。私の質問は：サーバー上のディレクトリにjpgファイルを保存するよりも画像を保存するためのより良い方法はありますか？（6 ^ 6（imho 6の6の累乗）の組み合わせの可能性があるため）
さようならジョギ
イメージを古き良きファイル形式でサーバーに保存します。
画像をデータベースに保存するのは効率的ではなく、価値がある以上の苦痛を伴う可能性があります。画像をフォルダー (おそらく独自の小さなフォルダー) に保存し、通常どおりにリンクします。これにより、ユーザーは画像を簡単にキャッシュできるようになり、サーバーへの影響が最も少なくなります。
ファイル構造からファイルを提供するのに必要なリソースは、データベースにクエリを実行し、情報を引き出し、そのデータが何であるかをユーザーに伝え、 1 秒、1 分、1 時間、1 日に何度も実行するよりもはるかに少ないリソースです。
一方、これらが大きなイメージであり、非常に多くのスペースを必要とする場合は、より多くのドライブ スペースを確保できるようになるまで動的に生成することを検討することもできますが、可能であれば最初のオプションをお勧めします。
最後に (そしておそらく最も重要なことですが、既成概念にとらわれずに考えてください)、これらの画像がどのようなものかはわかりませんが、他の方法で画像を作成することも検討してください。たとえば、タイルを張ることはできますか? 数百の画像を保存するのではなく、たとえば 10 のセグメントから数百の画像を作成できますか? それらを結合せずにそのままクライアントに送信して、それらが 1 つの画像のように見えるようにページ上に配置することもできるかもしれませんが、それは今では唾液のようなものです。
プラグインするつもりはありませんが、有益なタイプのストレージ atm が 1 つあります。GridFS です。
これは基本的に、データを MongoDB に配置するための手段です (他の DB には独自のストレージ メカニズムがあると確信しています)。
主な欠点は速度ですが、主な利点は、イメージをネットワーク全体 (およびグローバル) に分割して配布するのが非常に簡単であることです。しばらく CDN に ping して、さらに高速にすることもできます。
ただし、これはより大きなサイト用です。あなたのサイトは普通の個人的なブログ タイプのプロジェクトのように聞こえるので、サーバー上のディレクトリに画像を保存するだけだと思います。
ただし、繰り返しになりますが、常にディレクトリからサービスを提供することでさえ苦痛になる可能性があるため、特定のキャッシュメカニズムを配置できます。たとえば、画像のヘッダーを期限切れにしないで、ブラウザーが画像を可能な限り長くキャッシュするようにします。また、それらを Web サーバー (Apache など) 内にキャッシュします。これは、それらを常に保存しているディレクトリから直接提供したいとは思わないためです。そのため、予防策として（サイドサーバー構成に沿って）、サーバー側の言語などからキャッシュされていない画像を提供する可能性があります。
GD ツールの使用は非常に負荷が高く、CPU に負荷がかかるため、できる限り少ないことを試してみてください。この場合、CPU が非常に大きなイメージにバインドされているため、ファイル用の数メガのストレージは新しいインスタンスよりも安価です。
より多くのアドバイスと、Google にないものがあります。たとえば、Google からのストレート ヒット: http://developer.yahoo.com/performance/rules.html/