Должен ли я кешировать URL Carrierwave? - PullRequest
0 голосов
/ 12 апреля 2011

Мой веб-хостинг - Heroku, который не позволяет сохранять файлы в локальной файловой системе. Поэтому я использую Carrierwave для хранения своих файлов на Amazon S3.

В консоли я замечаю, когда делаю:

Photo.last.attachment.url

Возвращает:

 => "https://foobar.s3.amazonaws.com/uploads/users/1/photos/7/foo.jpg" 

Как и ожидалось. Однако этот процесс (возврата значения) в консоли занимает 2-3 секунды. Я думаю, что он пытается получить доступ к S3. Еще хуже, когда я загружаю веб-страницу с несколькими фотографиями, загрузка занимает много времени.

Кто-то упомянул, что, поскольку я удаленно храню свои файлы через S3, я должен кэшировать результат из " Photo.last.attachment.url ".

Это означает, что в моем БД мне нужно было бы два столбца:

: вложение и: attachment_url

: вложение будет для объекта загрузчика Carrierwave, а: attachment_url будет ссылкой на файл S3 напрямую.

Это то, что я должен делать? Есть ли лучшая альтернатива?

Ответы [ 2 ]

2 голосов
/ 25 апреля 2011

Это исправлено в последней версии Carrierwave. Лучше не кешировать, создание URL стоит дешево. Fog проверял файл при создании URL-адреса. Теперь поведение просто дать ссылку. Вы можете увидеть это обсуждение: https://github.com/jnicklas/carrierwave/issues/289 и https://github.com/jnicklas/carrierwave/issues/261

0 голосов
/ 12 апреля 2011

Я бы сделал кеширование.Мы сделали аналогичный подход, используя Paperclip.

В качестве альтернативы вы можете кэшировать представления (частичные), где используются URL-адреса.

...