私の仕事場でも同様の問題に取り組んでいます。
私たちは問題を引き起こしていた従来の構造を持っていましたが、システムはゆっくりとしかし確実に停止してしまい、理由を理解できませんでした。周りを掘り下げた後、私たちは1つのディレクトリにある数字ファイルに問題があることを発見しました。オリジナルのコードベースは、すべてのサムネイルとオリジナルの画像を同じフォルダに配置していて、68347個のファイルに達していたことがわかりました。これは明確な問題でした。また、複数のユーザーがイメージをアップロードしていて、サーバーがアップロードを処理していて、イメージのスケーリングとトリミングを処理していた場合、サーバーが遅くなることもわかりました。
私たちは、今直面している将来の課題に対して十分に頑強な新しいソリューションを実装しました。 - 画像用バケツタイムスタンプ付きフォルダ構造(ディレクトリ構造の決定は戦略パターンを使用して実装されているため、問題が発生した場合は簡単に新しい戦略を作成できます) - アップロードのみを処理しますアップロード時に - 画像がそのサイズで要求されたときにサムネイルが管理されます(これは、画像が最初に表示されるたびに1回だけ発生します) - トリミングとスケーリングのプロセスを処理するImagineライブラリに移動しましたImageMagikやGDより画質の面で優れた結果が得られています。ここで
Check it out on Git.は、ソリューションの周りの詳細のレベルです:私たちはベースディレクトリを持っているでしょう 1. アップロード(ロゴ、ユーザアバター、文書など)の種類ごとに例えば/.../uploads/logos/
我々は、ファイルが、例えばアップロードされたことをそれぞれの新しい一日のために新しいフォルダを作成します我々は何も1000の以上のファイルは、例えば、各フォルダに格納されていないであろうバケットフォルダ構造を持つことになり、これらのファイル内/.../uploads/20122011/
/.../uploads/20122011/0/
、/.../uploads/20122011/1000/
など
我々は擬似固有の名前(32文字長い)を生成するアップロードされた各画像は、我々はこれを生成するための時間+ランダムシードのMD5を使用しました。
アップロード時に、画像が別の画像に置き換えられた場合は、データベース内の関連する行を更新し、孤立したファイルをdbから削除します。
画像のサムネイルは、最初のリクエストで処理されます。すべて 注文が拒否
AllowOverrideの、 はすべて
RewriteEngine On
RewriteCond %{HTTP_HOST} ^static\.(.*)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} ^(.+)\.(jpg|jpeg|png|gif)$
RewriteRule ^.*$ /path/to/public/thumbnailer.php [NC,L]
から許可を許可これは「didnのファイルに対するすべての要求をリダイレクトします:私たちは、HTTPのconfファイルにfolllowingルールを使用して、これを実装しました私たちの親指で釘付けになったイメージだった。受け入れ可能なリクエストが処理され、新しいサムネイルが生成されるかどうか。
この回答をいただきありがとうございます。 2つの質問。 1.なぜアップロード時にイメージを拡大しないのですか(私は5サイズを使用しています)?私はAmazon S3を使用していますが、フォルダ構造の変更は何ですか? –
@Jonathan - アップロードされるすべての画像に対して5つの操作を順番に実行します。これは必要なオーバーヘッドになる可能性がありますが、すべてのイメージがすべての形式で表示されるわけではなく、すべての前処理を正当化することは間違いありません。したがって、アップロード中のオーバーヘッドを最小限に抑え、この処理の処理を最初の要求に移すことにしました。また、決して要求されない数十万のイメージを考え始めるときに、サーバースペースを節約します。 S3への試薬では、そうは思わない。馬鹿はそれについて私を引用しないでください! – GordyD
ええと、あなたが指摘しています。私が開発しているAPIは、おそらくInstagramのようなiOSアプリケーションを提供し、アップロードが完了した直後に画像が「見える」ようになります。別の「スレッド」に画像のサイズを変更しないでおく方法はありますか? –