冗談のために、彼らはこの作業がPhotoshopで手動でどれくらいかかるかを考え出した。 各写真に40秒をかけると、170年間の継続的な労働が発生します。 その後、彼らはパケットをEC2クラウドに送信できるかどうか、そして何時に到着するかを検討し始めました。 結果の量を見て、プログラマーは別の方法を探すことにしました。
その結果、4つの16コアサーバーを使用して、わずか9日間で1億3500万枚の写真の処理を完了することができました。 平均処理速度は1秒あたり180画像でした。
彼らは3つのツールを使用しました。
1. GraphicsMagick 、これはImageMagickのフォークであり、マルチプロセッサのサポートによりパフォーマンスが向上しています。 柔軟なコマンドラインオプションにより、パフォーマンスを微調整できます。
2. Perl。 彼がいなければどこにいるのでしょう。 しかし、これは必須のツールではありません。なぜなら、彼らはGraphicsMagick-Perlライブラリーを使用せず、すべてのコマンドは手動で作成され、他の言語で作成できるからです。
3. Gangliaモニタリングシステムを使用して、プロセスを視覚化するグラフを作成し、どのリンクが「ボトルネック」として機能し、画像検索、ファイルコピー、サイズ変更、オリジナルとの比較、結果のコピーを遅らせるかをすぐに理解します
GraphicsMagickをセットアップするために、管理者に提示されたさまざまな圧縮度の200個の画像を含むテストページを最初に生成しました。 彼らは許容できる品質の写真を選びました。 マニュアルがページ上の各画像の圧縮パラメータ、ファイルサイズなどに関する情報を表示しないことが非常に重要です。 （ファイル名であっても、これをほのめかすことはできません）-そのソリューションは完全に公平です。
その後、GraphicsMagickキットのすべてのフィルターの比較テストを行い、どちらがわずかに優れたパフォーマンスを提供するかを決定しました。
結果の画像は、170 x 135ピクセルのサイズであると想定されていました。 テスト中、サイズ変更前の画像のサイズを変更すると、フルサイズの原稿を直接サイズ変更するよりも品質と速度が向上することがわかりました。 GraphicsMagickの作成者はこれを確認し、JPEG形式自体でサポートされているサムネイル要求機能の使用を提案しました。
その後、プログラムは実サーバーでのテスト用に起動され、「ボトルネック」はCPUではなくファイルシステム（NFSシークタイム）であることが判明しました。 実際、CPUは1％しかロードされていません。 並列写真検索のプロセスを開始するには、スクリプトを書き直す必要がありました。これにより、生産性が大幅に向上し、1秒あたり最大15画像になりました。 しかし、この速度ではすべての作業に104日かかるため、この結果は再び満足できません。
16コアのNehalemサーバーを使用することにしましたが、GraphicsMagickは各タスクを16の部分に分散し、それらを一緒に組み立てることがわかりました。 つまり、彼は小さなタスクごとに冗長な作業を行っています。その結果、サイズ変更の速度は毎秒10イメージに低下しました。 設定を変更する必要があり、状況は修正されました。
その後、Perl（子供）とGraphicsMagick（スレッド）のスレッドの最適な比率を決定するために、別の重要なテストを実施しました。 結果を表に示します。
タスクごとに2つのプロセッサコアを使用すると、最高のパフォーマンスが得られることがわかりました。 理論的には、1台のサーバーで1秒あたり140枚の画像-推定速度は11日間です。 それが私たちに必要なものでした。
その後、4つの16コアNehalemサーバーでプロセスが開始されました。 実際には、速度はそれほど速くありませんでした。NFSによってすべてが遅くなりましたが、合計で4つのサーバーが毎秒約180のイメージを安定して提供しました。
