2014-01-27 5 views
4

Я в процессе обновления с Ruby 1.8.7 до 1.9.3 и от Rails 2.3 до 3.2. В рамках этого обновления я перехожу из Paperclip 2.2.9 в 3.5.2. Моя версия ImageMagick - 6.8.6. Одна из проблем, которые я обнаружил как часть процесса обновления, заключается в том, что производительность загрузки очень плоха, когда дело доходит до больших текстовых файлов (~ 1 МБ). Для файлов, о которых идет речь, не обязательно должны быть .txt-файлы, все в текстовом формате (файлы .xml, например) также выполняются.Проблемы с производительностью при загрузке больших текстовых файлов через Paperclip

Для справки, здесь моя установка Скрепки:

has_attached_file :attachment, 
    :url => "/shared_documents/:id/:basename.:extension", 
    :path => ":rails_root/user_uploaded_content/shared_documents/:id/:basename.:extension" 

Для простоты я опускаю наши валидации и так далее, как мы просто проверить размер файла и наличие.

Наблюдая за запущенными процессами на моей машине разработки, кажется, что узкое место возникает, когда Paperclip вызывает команду ImageMagick identify. Вызов identify в различных файлах через командную строку позволил мне проверить, что метаданные возвращаются почти сразу для файлов изображений, но большие текстовые файлы без изображения занимают очень много времени.

Для моего приложения я разрешаю пользователям загружать документы в любом формате, который им нравится, поэтому я должен иметь возможность эффективно обрабатывать как изображения, так и текстовые файлы. Кто-нибудь еще столкнулся с этой проблемой? Есть ли способ выборочно отключить вызов identify в определенных форматах файлов в папке, но не в других? В противном случае мы могли бы жить, просто не вызывая identify, если это вариант. Возможно, есть способ настроить ImageMagick более грациозно обрабатывать большие текстовые файлы?

ответ

2

Если вы на самом деле не обрабатываете файлы, просто скажите Paperclip, чтобы они не обрабатывали их. Из документации Paperclip вы можете сделать это несколькими способами. Одним из них является поставить пустой список стилей в модели:

has_attached_file :attachment, 
    styles:{}, 
    url: "/shared_documents/:id/:basename.:extension", 
    path: ":rails_root/user_uploaded_content/shared_documents/:id/:basename.:extension" 

или, вы не можете просто поставить Нет процессоров

has_attached_file :attachment, 
    processors:[], 
    url: "/shared_documents/:id/:basename.:extension", 
    path: ":rails_root/user_uploaded_content/shared_documents/:id/:basename.:extension" 

или, вы могли бы использовать before_post_process обратного вызова в модели и возвращать ложь чтобы остановить этот процесс, но Paperclip можно назвать identify первым, чтобы проверить файл, который сделал бы этот вариант бессмысленный для вашей ситуации:

has_attached_file :attachment, 
    url: "/shared_documents/:id/:basename.:extension", 
    path: ":rails_root/user_uploaded_content/shared_documents/:id/:basename.:extension" 

before_post_process :skip_processing 

def skip_processing 
    false 
end 
+0

усиливая before_post_processing callbac k был ключевым! Как оказалось, проблема с производительностью не связана с настройкой, описанной выше, а скорее, когда изображение было скопировано в постоянный журнал изменений, где мы делаем пост-обработку, чтобы вытаскивать эскизы. В конце концов, я проверил тип контента приложения, чтобы выборочно обрабатывать или нет. – emcallaway

Смежные вопросы