0

S3にアップロードされた画像のサムネイルを動的に表示するスピーディーがあるかどうかを尋ねたかっただけです。プロフィール写真としましょう。

私はこれらの写真の3つのサイズを実際に表示しています。150x150と25x25です。現在、S3ではなくサーバー上でオンザフライで動的にサイズを変更しています。

http://www.mydomain.com/images/25X25/image.jpg

上記は、サムネイルが存在するかどうかを確認し、存在しない場合は生成するURLです。現時点では3つのサイズしか許可していません。

すぐにS3に移行します。S3でもそのようなことが可能ですか？元の画像を取得し、サイズを変更してから、S3で再アップロードする必要がありますか？もちろん、キャッシュを有効にして、すべてオンザフライで行う必要がありますか？

または、実際の画像自体をアップロードするときにこれを行う必要があります-さらに2つのサムネイル（読みやすいファイル名lile image_25_25とimage_150_150を使用）を作成し、それらも一緒にアップロードしますか？

したがって、最終的にはすべてのアップロードで

https://bucket.s3.amazonaws.com/image.jpg
https://bucket.s3.amazonaws.com/image_25_25.jpg
https://bucket.s3.amazonaws.com/image_150_150.jpg

どちらが良い選択肢だと思いますか？または提案をお願いします-皆さんに本当に感謝します（えーと-いつもそうです-これは助けを得るのにとても素晴らしい場所です！）

乾杯！

4

1 に答える 1

2

あなたのアプローチは、この変更を行うための主な目標、処理する予定のアップロードボリュームの種類、これらのサムネイルでの一般的なヒット率の種類、およびコストに関する制約に大きく依存すると思います。このサムネイルを実行する方法（つまり、保存のための処理と保存のコストを実行するために必要なサーバーリソース）。

コストに関係なく、エンドユーザーの画像のダウンロード時間を短縮することが最も重要なことである場合は、アップロード時にサムネイルを作成するのがおそらく最良の選択です（S3バケットの前でCloudfrontを使用する場合もあります）。 。これにより、アプリケーションは、これらの画像のリクエストを動的に処理しようとするビジネスから外れます。1つの欠点は、エンドユーザーのアップロードプロセスに時間がかかる可能性があることです（エンドユーザーに成功を示す前にS3でファイルを作成して利用できるようにする必要がある場合）。もちろん、サーバーリソースと画像が使用されるかどうかに関係なく、アップロードされたすべての画像のストレージスペース。

最小限のリソースとストレージの利用に関心がある場合は、引き続きWebアプリケーションを使用して画像リクエストを処理し、S3で必要に応じて画像を作成するというアプローチを取ることができます。s3fs（キャッシュ機能がオンになっている）のようなものを使用して、これらのイメージをアプリケーションサーバーのローカルマウントで利用できるようにして、プロセスを高速化することもできますが、全体として、この動的なコンテンツ提供アプローチには反対することをお勧めします。目標は、最高のユーザーエクスペリエンス（つまり、最速のダウンロード）を提供することです。

于 2013-01-14T20:53:07.527 に答える