4

これがそのことです。今、私はこのeコマースWebサイトを持っており、人々は自分の製品の写真をたくさん送ることができます。すべての画像はAmazonのS3に保存されています。サムネイルなどが必要な場合は、S3にあるかどうかを確認します。そうでない場合は、1つを処理して、S3に送信し、ブラウザーに表示します。さまざまなサイズのサムネイルはすべてS3に保存され、リクエストごとにサムネイルの可用性を確認するのはお金がかかります。サイトがもっと注目され始めたら（もしそうなら...）、私は多額の支払いをするのではないかと心配しています。

代替案を考えて、S3で元の画像だけを保持し、要求ごとにその場で画像を処理することを考えていました。そのようにCPU使用率を計算することになると思いますが、どこまで行けるかを確認するためのベンチマークは作成していません。重要なのは、S3でリクエストを行ったり、より多くの画像を保存したりするのにお金をかけず、ユーザーのブラウザにすべてをキャッシュできるということです。それを行うのはそれほど安全ではないことを私は知っているので、それが私がこの質問をここに持ってくる理由です。

どう思いますか？どうすればこれを解決できると思いますか？

4

3 に答える 3

5

アップロード時にサイズを変更し、すべてのバージョンをS3に保存します。

たとえば、より大きな画像（1200x1200〜200kb）があり、3つのサイズ変更されたバージョン（300x300、120x120、および60x60）を作成する場合、約16％または32kb（私のテスト画像ではYMMV）を追加するだけです。100万枚の画像を保存する必要があるとしましょう。これは約30GB多い、つまり月に4.5ドル余分になります。Flickrは、（2007年に）20億枚の画像を持っていると報告しました。これは、月に9千ドル余分にかかるもので、それほど大きくても悪くはありません。

もう1つの大きな利点は、AmazonのCloudFrontを使用できることです。

于 2009-06-27T05:23:24.597 に答える
3

S3からクライアントにプロキシしている場合（これはあなたが行っているように聞こえます）、2つの最適化を検討してください。

  1. アップロード時に、画像のサイズを一度に変更し、パッケージ（tar、XMLなど）としてアップロードします
  2. これらのイメージパッケージをフロントエンドノードにキャッシュします。

「イメージパッケージ」は、S3では無料ではないPUT / GET/DELETE操作の数を減らします。画像サイズが4つある場合は、4つ縮小します。

キャッシュはS3トラフィックをさらに削減します。これは、ワークフローには通常サムネイルが表示されると思います->クリックすると大きな画像が表示されます。

さらに、クラスターを使用している場合は事前にキャッシュされるように、Webノードにアクティブにプッシュされる「ホットイメージ」キャッシュを実装できます。

また、Slicehost<->S3の使用はお勧めしません。交通費はあなたを殺すでしょう。本当にEC2を使用して、大量の帯域幅（お金!!）を節約する必要があります。

プロキシを使用していないが、クライアントに画像のS3 URLを渡す場合は、すべての画像を前処理する必要があります。次に、それらをチェックする必要はありませんが、URLをクライアントに渡すだけです。

毎回画像を再処理するにはコストがかかります。すべての画像のサイズが変更されていると想定できる場合は、Webノードでの作業量が減り、すべてが高速化されることがわかります。これは、複数のS3リクエストを実行していないため特に当てはまります。

于 2009-06-27T14:09:46.510 に答える
2

次のローカルキャッシュを保持します。

  1. S3にある画像
  2. 最も人気のある画像のキャッシュ

次に、どちらの状況でも、ローカル参照があります。イメージがローカルキャッシュにない場合は、ローカルキャッシュをチェックして、S3にあるかどうかを確認できます。最も人気のあるアイテムのS3トラフィックを節約し、ローカルキャッシュにないアイテムのS3をチェックするときのレイテンシーを節約します。

于 2009-06-26T22:16:34.637 に答える