私たちの Web サーバーは、結果を Web クライアントに送信する前に、大きな画像の多くの構成をまとめて処理する必要があります。サーバーは 1 時間あたり数千の要求を受信する可能性があるため、このプロセスはパフォーマンスが重要です。
現在、私たちのソリューションは HD から PNG ファイル (それぞれ約 1MB) をロードし、それらをビデオ カードに送信して、合成が GPU で行われるようにします。最初に、XNA API によって公開された PNG デコーダーを使用して画像を読み込んでみました。パフォーマンスがあまり良くないことがわかりました。
問題が HD からの読み込みにあるのか、PNG のデコードにあるのかを理解するために、ファイルをメモリ ストリームに読み込み、そのメモリ ストリームを .NET PNG デコーダーに送信することで問題を修正しました。XNA を使用した場合と System.Windows.Media.Imaging.PngBitmapDecoder クラスを使用した場合のパフォーマンスの違いは重要ではありません。ほぼ同じレベルのパフォーマンスが得られます。
ベンチマークは、次のパフォーマンス結果を示しています。
- ディスクからの画像のロード: 37.76ms 1%
- PNG のデコード: 2816.97ms 77%
- ビデオ ハードウェアへの画像の読み込み: 196.67ms 5%
- 構成: 87.80ms 2%
- ビデオ ハードウェアから合成結果を取得: 166.21ms 5%
- PNG へのエンコード: 318.13ms 9%
- ディスクへの保存: 3.96ms 0%
- クリーンアップ: 53.00ms 1%
合計: 3680.50ms 100%
これらの結果から、PNG をデコードするときが最も遅い部分であることがわかります。
そのため、PNG のデコード時間を短縮できる PNG デコーダーがないのではないかと考えています。画像を非圧縮のままハードディスクに保存することも検討しましたが、1 枚の画像のサイズが 1MB ではなく 10MB になり、ハードディスクには数万枚の画像が保存されているため、すべての画像を圧縮せずに保存することはできません。圧縮。
編集:より有用な情報:
- ベンチマークは、20 個の PNG 画像の読み込みとそれらの合成をシミュレートします。これは、本番環境で受け取るリクエストの種類にほぼ対応しています。
- コンポジションで使用される各画像のサイズは 1600x1600 です。
- このソリューションには、ここで説明しているような負荷分散されたサーバーが 10 台ほど含まれます。したがって、追加のソフトウェア開発作業は、ハードウェア コストの節約に見合う価値があります。
- デコードされたソース画像をキャッシュすることを検討していますが、各コンポジションは完全に異なるソース画像で行われる可能性が高いため、キャッシュ ミスは高くなり、パフォーマンスの向上は低くなります。
- ベンチマークは質の悪いビデオ カードで行われたため、まともなビデオ カードを使用すると、PNG のデコードがさらにパフォーマンスのボトルネックになることが予想されます。