2012-05-03 5 views
10

sorl-thumbnailsとS3でセロリタスクを使う方法を探すときに "セロリを使う"以外に何も表示されないのは驚きです。リモートストレージでsorlサムネイルでセロリを使用するためのポインタ?

問題:リモートストレージを使用すると、サムネイルエンジンがリモートストレージからオリジナルをダウンロードしている間に、サムネイルを生成するときに大量の遅延が発生します(サムネイルが多いページでは100s +と思う)。

ここではsorl内でセロリのタスクを設定するのに適していますが、どうすればいいですか?

あなたの経験やアイディアのいずれかが非常に高く評価されます。

このタスクを遅らせるための便利な場所を見つけるためにSorlの内部を掘り起こすことにしますが、これが以前に解決されていればさらに興味深いことがいくつかあります。

  1. すぐに返される画像はありますか? Sorlには返されたイメージが実際のサムネイルではないと何とか言わなければなりません。セロリがタスクを終了するときにキャッシュを無効にする必要があります。

  2. はきれいに複数のサムネイル生成要求を処理私は一時的ヒットを果たすことができ、プロキシキャッシュを逆nginxのを使用してこれを解決してきた、今の

(のみ与えられたキャッシュキーの最初のいずれかが必要)バックエンドは高価なページを生成する時間を費やします(巨大な製品グリッド上で巨大なPNGをサイズ変更する)が、非常に手作業です。

+0

http://djangosnippets.org/snippets/1562/助けてもらえます – jpic

+0

@jpicありがとうございますが、それは3歳です。sorlはすでにリモートストレージで動作しています。私が助けが必要なのは、リモートストレージサムネイルを非同期的に生成することです。 –

+0

@YujiTomitaこれで進歩はありましたか?あなたの発見を聞くのは良いでしょう。 – jamesc

答えて

3

私はあなたがしたいと思うのは、メソッドをオーバーライドするカスタムクラスにTHUMBNAIL_BACKENDを設定すると思います。その関数にサムネイルを生成する代わりに、関数に与えられているのと同じ引数で_create_thumbnailを呼び出すセロリタスクをキックします。サムネイルはリクエスト中に利用できませんが、バックグラウンドで生成されます。

3

私はSorlがS3ストレージで正しく動作することを理解していますが、非常に遅いです。

私はあなたが必要とする画像のサイズを知っていると信じています。

イメージがアップロードされた後にセロリタスクを起動する必要があります。あなたが sorl.thumbnail.default.backend.get_thumbnail(file, geometry_string, **options)

に電話すると、Sorlはサムネイルを生成してS3にアップロードします。次に、テンプレートからイメージを要求すると、イメージは処理されている間にプレースホルダのサムネイルイメージを処理するためのクリーンな方法として、既にキャッシュされ、Amazonのサーバーから直接配信されています。

このためには、Sorlバックエンドを無効にする必要があります。新しい引数をget_thumbnail関数に追加します。 generate=False。あなたはセロリパスgenerate=True

からこの関数を呼び出しますと機能の変更には、ロジックですので、親指が存在せず、generateがTrueの場合は、単に標準のバックエンドのように動作しますが、generateがfalseの場合、あなたのプレースホルダイメージがで戻ったときのようなテキスト「今すぐイメージを処理し、後で戻ってくる」backend._create_thumbnailを呼んではいけません。サムネイルが誤って削除される可能性があると思われる場合は、この場合にタスクを起動することができます。

私は、これはあなたがSorleryを使用することができます

2

に役立ちます願っています。ソルとセロリを組み合わせて、労働者を介してサムネイルを作成します。ワーカースレッドの外部でファイルシステムにアクセスしないように注意しています。

THUMBNAIL_DUMMY_SOURCEを適切なプレースホルダに設定すると、直前に返されたサムネイルを制御することができます。

ジョブはサムネイルが最初に要求されたときに作成され、後続の要求はワーカースレッドが完了するまでダミーイメージとして提供されます。

+0

長すぎるコメント:これは素晴らしいようです。どうもありがとうございます!私は次のプロジェクトが始まるとすぐにそれをチェックします。これはリモートストレージを使用する際の大きなボトルネックになっています.Djangoエコシステムでリモートストレージを使用することによって追加されたエンジニアリングの課題と、アプリケーションサーバーを本当にスタンドアロンにすることによって解決される操作障害があります。 –

+0

これは興味深い実験でしたが、CloudinaryやImgixのようなものを使うべきだと思います。 – Aidan

関連する問題