私たちは、敷地内のアプリケーションをAzureクラウドに移動させようとしています。社内の企業ユーザは、管理インターフェースを介して当社のウェブサイトにフルサイズの画像を定期的にアップロードします(Azureブロブストレージに送信されます)。サイトでは、要求されたときに正しいイメージサイズを作成する責任があります。だから、今何が起こっているのですか(前提環境で):Azure/CDNに対するプログラミング
1)ユーザーはフルサイズのファイルをアップロードします。
2)GetImage HTTPハンドラ(つまりhttp://www.site.com/GetImage.aspx?imageid=15&height=100&width=100)で小さいバージョンが要求されると、ハンドラは以前にそのサイズの画像を作成しているかどうかを確認します。そうであれば、レスポンスストリームに直接書き込みます。そうでない場合は、サイズを変更して「/ iamges/cache」ディレクトリに保存し、サイズ変更されたイメージをレスポンスストリームに書き込みます。
3)次にそのファイルがそのサイズで要求されると、以前に作成されたイメージが返されます。
は、だから私は、Azureのブロブストレージを用いた機構の同じタイプを実装したいが、私は懸念のカップルがあります:
1)私は単にブロブが存在するかどうかを確認することはできません。最初にBLOBをダウンロードしてから、FetchAttributesを呼び出して例外がスローされるかどうかを確認する必要があります。ただし、これを実行すると実際にイメージがダウンロードされます。それで、イメージの要求数が2倍にならないのです(1つは存在するかどうかを確認し、もう1つはユーザーに表示する)。
2)イメージが必要なサイズでないとします(blob /images/cache/image_15_100_100.jpgは存在しません - id#15,100x100ピクセル)。だから私はCDNへのリクエストを一度ヒットしてそれが存在するかどうかを確認しています。今私は、おそらく5-10 MBのフルサイズのイメージをダウンロードしなければなりません(高速である私たちのオン・プレミス・ファイルシステムから読み込むのとは対照的に)、5-10 MBのイメージをメモリにロードし、サイズを変更してからCDN。これは時間がかかるようです。特に、1回のリクエストでこれらの画像のうち10〜15個を持つことができたときです。
私はAzureが比較的新しいと知っていますが、このタイプのBLOBストレージとのやりとりの「ベストプラクティス」に近いものはありますか?私が検討できる別のアプローチがありますか?これはイメージのサイズ変更のためのオーバヘッドのように思えるので、私は何かを見逃しているか、別の解決策を見落とさなければならないと考えています。
画像サイズの要求は事前に決められているのか、それとも完全に恣意的ですか? – Omar
これは現在はあらかじめ決められていますが、ビジネス要件によって、その場でサイズを変更する必要があることが示されています。私はすでに正しいサイズでそれらをプリロードすることを考えました。 :) – Scott
Azure SQLを使用して、同じネットワーク上の誰かがローカルネットワーク、キャッシュなどを介して取得できるイメージを要求した場合、特定のサイズの最後のイメージダウンロードへの参照を含むBlobおよびメタデータを保存しないのはなぜですか?あなたはまだダウンロードイメージを持っています – Lloyd