現在、画像のサイズをリアルタイムで変更しています。ユーザーは1日あたり約5万から10万の画像をアップロードしています。そして、私たちのサーバーは、24時間年中無休で100％のCPU使用率に固定されています。また、ページの読み込み時間が遅くなります。ラムは問題ではありません。
24ギガヘルツのRAMを搭載したデュアルCPUインテルXeonL56302.13GHzサーバーがあります。また、単純な画像サイズ変更スクリプトを使用して、元の画像からサムネイルを作成しています。しかし、これはCPUを最大限に活用しています。
この問題をハードウェアとソフトウェアの両方で攻撃したいと思います。
ハードウェア側では、DualXeon3GHzプロセッサを搭載した別のサーバーを注文します。このサーバーは、ウェブサイトとは別に画像処理を処理します。
ソフトウェアについては、経験豊富な人に、CPUオーバーヘッドの低い画像を処理するためにどのようなソフトウェアを使用しているかを尋ねたいと思います。
どんな考えでもいただければ幸いです。
大量のユーザーのほとんどは、アップロードを変更せずに BLOB ストレージに直接送信し、要求に応じて動的にサイズ変更を実行する方がよいことに気付きます。このアプローチには多くの利点 (俊敏性、モバイル サポート、制御) がありますが、主にリソースの使用率を下げることができます。ほとんどのコンテンツは注目を集めることはありません。なぜそれにリソースを浪費するのですか？
私の知る限り、.NET のサーバーに適した唯一のソフトウェアであるImageResizerを既にご覧になっているようです。また、さまざまなパイプラインを提供しますが、それぞれに独自のトレードオフがあります。生の速度が必要な場合は、WIC パイプラインを使用してください。現在のスクリプトよりも 10 倍から 20 倍優れたパフォーマンスが得られると思います。WIC パイプラインの品質は、既定のパイプラインほど良くはありませんが、2 倍から 4 倍高速であり、ほとんどの画像で違いを見分けることはできません。
私は多くの企業が 100 万枚や 1000 万枚の画像の壁を超えて拡大するのを支援してきました。避けるべきアーキテクチャの落とし穴がいくつかありますが、この規模では、ニーズを非常に詳細に検討することをお勧めします。Varnish または CDN はオプションですか? これらは、500 画像/秒の壁を超えてスケーリングするのに大幅に役立ちます。
まず、画像処理をメインサーバーから分離することをお勧めします。
最良の答えは、特定の状況からの詳細（どのソフトウェア環境、画像のサイズ変更に使用されるソフトウェア、構成方法など）によって異なります。そこで最適化すると、速度が大幅に向上する可能性があります。たとえば、複数のコアがありますが、GPUベースの処理を使用できますか？
とはいえ、すべての画像サイズ変更操作は他の操作から独立しているため、一般的な解決策があります。必要な数のサーバーに作業を簡単に配布できます。1つ（または必要に応じて複数）の追加の画像処理サーバーを構築します。次に、サイズ変更リクエストが配布されるようにします。これは、いくつかのレベルで実行できます（WebクライアントからURLを介してサイズ変更が呼び出されますか？送信するURLでサーバー名をランダム化します。ビジネスレイヤーによってサイズ変更が呼び出されますか？そこでサーバー名をランダム化します）。
より具体的な回答が必要な場合は、詳細をお知らせください。
まず、リアルタイムで処理する必要がありますか? –そうでない場合は、他のサーバーを利用するキューベースシステム/現在のサーバーの静止時間をサムネイルを処理するために見ることができます.
画像のサイズ変更は 1 回だけですか、それともユーザーが再度画像のサイズ変更を要求する可能性がありますか? – もしそうなら、キャッシングを検討する必要があります。
再圧縮される画像のサイズと、一度に処理される画像の数は? (1 日中分散している場合)?
ページの読み込み時間の遅延は、ポストバック中に画像のサイズを変更したことが原因ですか? – もしそうなら、その命令を新しいスレッドに追加すると、応答時間が改善されます。