3

画像のサムネイルが多いため、CPU の負荷が高い Web サイトを実行しています。

これは私が現在やっている方法です：

  1. ユーザーがサーバーに画像をアップロード
  2. サーバーはコピーを保持し、Amazon S3 にイメージを保存します
  3. サムネイルが要求されると、サーバーはローカル コピーを使用してサムネイルを生成し、S3 に保存します。次に、S3 URL をクライアントに提供します
  4. 後続のリクエストは次のように最適化されます。サーバーは S3 URL を memcached にキャッシュするため、再度作業を行うことはありません。ファイルが存在する場合、サーバーは二度とサムネイルを生成しません。サーバーは中サイズのサムネイルを使用して小さなサイズのサムネイルを生成するため、必要のない大きなファイルを操作しないでください。

現在、私は Linode 4G インスタンス (4x 優先度の 8 コア、4GB RAM) でホストしており、最適化と 70% の memcached ヒット率にもかかわらず、私の平均 CPU は 170% です。8 つの CPU すべてが同時に動作し、それらの多くで 100% のスパイクが頻繁に発生するのを常に確認しています。

Django アプリケーションを提供するために nginx と gunicorn を使用しています。サムネイルは PIL で生成されます。

このアーキテクチャを改善するにはどうすればよいですか?

私はいくつかの可能性について考えていました：

＃1。最も簡単な方法: 前にロード バランサーを備えた 2 番目の同一のサーバーを追加して、負荷を共有します。

これに関する問題は、2 つのサーバーがローカル イメージ キャッシュを共有しないことです。そのような共有をネットワークドライブに配置することでこれを解決できますか?それとも、遅延が最終的に利益を妨げますか?

＃2。少し難しい: 2 番目のサーバーで実行される別の Web サービスとして、アプリからサムネイル コードを分割します。この方法では、メイン アプリケーションとデータベースが高い CPU 使用率に悩まされることはなく、Web ページは高速に処理されます。いずれにせよ、サムネイルはすでに JavaScript で非同期に提供されています

他のソリューションを推奨できる人はいますか?

4

2 に答える 2

1

パフォーマンスの問題がサムネイルに起因していると確信していますか? OK、あなたはそれをチェックしたと思います。

ユーザーが画像をアップロードした直後に (またはすぐに)、2 つのサムネイルを縮小して S3 にアップロードできます。このようにして、これらのサムネイルをチェックし、memcached で IPC を実行するすべての HTTP リクエストに浪費している不必要な CPU 負荷を節約できるはずです。

于 2013-11-05T18:13:47.693 に答える
0

ある意味では、個別の画像サイズ変更タスク間に依存関係がないため、複数のサーバーに簡単に分散できるという点で、問題は「良い」問題です (または、少なくとももっと悪い可能性があります)。いくつかのコメント:

  1. 画像のサイズ変更操作を高速化するためにできることがあるかどうかを確認しましたか? （Googleがこれを提起しましたが、それが助けになるかどうかはわかりません：http://dmmartins.appspot.com/blog/speeding-up-image-resizing-with-python-and-pil）それでも必要だとわかったとしてもサーバーを追加するには、各サイズ変更操作をより効率的にするためにできることはすべて、各サーバーをより遠くまで進めます。

  2. ユーザーが増え続ける場合、最終的には「スケールアウト」する必要がありますが、短期的には、サービスの次の「層」にさらに 80 ドルを支払うだけで問題を解決できる可能性があります (8 コア8 倍の優先度）。

  3. 画像のサイズ変更がアプリの唯一のボトルネックですか? 画像のサイズ変更が「無料」だった場合、ページのレンダリングや DB クエリの実行などによってスループットが制限される前に、既存のサーバーをどれだけ拡張できますか? わからない場合は、シミュレートされた負荷テストを行って調べることをお勧めします。ページのレンダリング、DB クエリなどもボトルネックである場合、またはすぐにボトルネックになる場合は、とにかくアプリを配布する必要があるためです。その場合、サムネイルを 2 番目のサーバーで Web サービスとして実行するのではなく、メイン アプリでサムネイルを維持し、今すぐ配布することもできます。

  4. メインアプリを配布するか、サムネイルを別のサーバー上の別のアプリに分割するかに関係なく、各サムネイルが S3 のどこに保持されているかを追跡するために、ある種の信頼できるストアが必要です。その情報は、memcached、データベース、または必要な場所に保持できます。それは本当に問題ではありません。memcached に保存したとしても、2 つのサーバー間でキャッシュを共有できないわけではありません。一方のサーバーは、もう一方のサーバーで実行されている memcached インスタンスに接続できます。

別のサーバーに保持されているキャッシュをチェックする「待ち時間」が「利益を妨げる」かどうかを尋ねました。あなたがそれについて心配する必要はないと思います。問題はスループットであり、レイテンシではありません。これらの高レイテンシーのネットワーク操作は、非常にうまく並列化されます。したがって、より多くのリクエストを並行して処理するだけでも、CPU を最大限に活用できます (これが現在のリソースのボトルネックです)。

于 2013-11-05T20:47:55.487 に答える