Обработка большого количества изображений, проблема с скоростью и загрузкой

[no_santa]

Обработка большого количества изображений, проблема с скоростью и загрузкой

Встала задача обработка большого количества изображений. На каждый запрос необходимо на лету делать ресайз и накладывать ватермарки на 100-5000 картинок в разрешении от 640х480 до 2000x2000. В среднем 500-1500 полноцветных картинок 1000Х1000.

Сейчас делаю на GD. На запрос реально уходит от 6 секунд до 30 минут, сервер загружен по полной. Уже делаю организацию очереди, вопрос - можно-ли еще как-то ускорить?

На текущий момент вычищаю память после каждой обработки - визуально увеличило скорость на 5-10%. Что еще можно сделать?

 

[Gremboloid]

а что мешает заранее создавать и сохранять картинки вотамарками и ресайзом?

 

[Adelf]

необходимо пересмотреть функционал. почти наверняка можно сделать по другому. PHP не будет в адекватное время генерить столько картинок.

 

[Alexandre]

Уже делаю организацию очереди, вопрос - можно-ли еще как-то ускорить?

30 мин - это жесть!
мы обработку картинок делаем на отдельном сервере, чтоб сервер не был загружен по полной
обработка должна быть не на лету... и наверное ты это уже понял.
и не удивительно что он загружен по полной

Если все так уж плохо, то выбивай у руководства деньги на сервер статики и конвертации.

как использовать очередь я тебе уже отвечал, при необходимости могу повторить. для закачки на другой сервак используем WebDav:
- статический контент (графика) хранится на другом сервере (сторадж)
- в темплаитах прописан урл статического контента
- при аплоадинге статический контент с помощью WEBDAV заливается на сторадж
- по окончании заливки имя файла кладется вв очередь

На сервере конвертации по крону считывают очередь и производят конвертацию, как конвертация контента закончилась, статус отправляется клиенту (напрямую через memcache).
Клиентская часть опрашивает статус конвертации... при получении статуса Ок - урл временной картинки ("в процессе") подменяется на урл сконвертированной.

Все динамично и красиво.

-~{}~ 17.08.09 12:16:

необходимо пересмотреть функционал.

ясное дело, что сделано через Ж...

 

[no_santa]

Спасибо за ответы!

Картинки обрабатываются именно динамически, это не пересматривается, т.к. в этом суть ТЗ.

Очередь хочу сделать на базе, прям в журнале. Статусы обработки устанавливает обработчик, клиент ежеполминутно считывает очередь.

Как лучше организовать обработку картинок? Операции де-факто две - ресайз и наложение.

 

[SiMM]

Интересно, что за задача такая, в которой клиенту на свой единственный HTTP-запрос необходимо получить в отклике до 5000 тысяч динамических картинок разрешением до 4 мегапикселей?

 

[Alexandre]

Картинки обрабатываются именно динамически, это не пересматривается, т.к. в этом суть ТЗ

тогда тебе и 8-ядерника не хватит,
а предполагаемая нагрузка на железо?

-~{}~ 17.08.09 14:00:

Как лучше организовать обработку картинок? Операции де-факто две - ресайз и наложение

1) реесайз
2) наложение

не следует тупо следовать ТЗ
Заказчика надо убедить и убедить аргументированно...

 

[A1x]

Если все так уж плохо, то выбивай у руководства деньги на сервер статики и конвертации.

есть еще такая интересная штука как Amazon Elastic Compute Cloud (Amazon EC2)
например если нужны некоторые значительные выч. ресурсы - запускаем там один или несколько экземпляров виртуальных машин,
выполняем задачу и выключаем. Оплата идет только за время работы (почасово) Это может быть выгодней чем держать свой железный сервер.

ЕС2 машины представляют собой обычный линукс - можно заходить по ssh, запустить веб сервер, установить/запустить любой другой линуксовый софт.

 

[Alexandre]

выполняем задачу и выключаем. Оплата идет только за время работы (почасово) Это может быть выгодней чем держать свой железный сервер.

если задачки редкие, то - да. Судя по тому, что процессор зашкаливает с нагрузкой, то тут особо не разбежишься. и вообще, как себе представляешь использование удаленного сервиса для удаленной конвертации:
- включили вирт машину
- залили файл
- сконвертировали
- слили...
- закрыли вирт машину...
не много ли действий?

 

[Фанат]

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

До ответа на вопрос SiMM тут вообще нечего в этом топике делать. Кроме общения со своими собственными фантазиями.

 

[A1x]

конечно надо считать затраты для каждого конкретного случая.
возможно стоит пересмотреть сам процесс

вообще там есть средства автомасштабирования
Auto Scaling
Amazon CloudWatch

Amazon CloudWatch дает возможность проводить мониторинг ваших Amazon EC2 машин и Elastic Load Balancers в реальном времени.

Amazon CloudWatch включает Auto Scaling что позволяет динамически добавлять или удалять ЕС2 машины в зависимости от данных Amazon CloudWatch. Auto Scaling бесплатен для пользователей Amazon CloudWatch.

 

[no_santa]

Автор оригинала: Фонат
Вообще, такая схема работает.
Но опять же, я очень сильно сомневаюсь, что у афтара задача, требующая такой тяжелой артиллерии.

До ответа на вопрос SiMM тут вообще нечего в этом топике делать. Кроме общения со своими собственными фантазиями.

Ты знаешь, как я тебя люблю... Поэтому взял тему в закладки - дам урл на релиз, буквально недельки через 2

-~{}~ 18.08.09 21:58:

Действительно-ли ImageMagick быстрее GD? Поможет-ли переезд на ImageMagick в данном случае?

 

[dimagolov]

no_santa, ты все еще не объяснил зачем

...клиенту на свой единственный HTTP-запрос необходимо получить в отклике до 5000 тысяч динамических картинок разрешением до 4 мегапикселей?

 

[Фанат]

жду с нетерпением

 

[no_santa]

это суть ТЗ.

 

[cDLEON]

Если тебе в ТЗ напишут убить себя большущей деревянной ложкой вставленной в твой зад, ты тоже будешь пытаться это выполнить и твердить всем - что это суть ТЗ ?

На текущий момент вычищаю память после каждой обработки - визуально увеличило скорость на 5-10%.

Одного меня это "улучшение" улыбнуло?

 

[dimagolov]

no_santa, прикол в том, что в ТЗ должно быть оговоренно не только кол-во картинок, которые надо сгенерить, но и время генерации. А из этого надо делать вывод об аппаратной части, которая требуется. Иначе оптимизировать нечего, генерит и ладно, а какое время это заказчика (ТЗ) и исполнителя волновать не должно

 

[Фанат]

отстаньте вы от него
это бесполезно

 

[no_santa]

Автор оригинала: dimagolov
no_santa, прикол в том, что в ТЗ должно быть оговоренно не только кол-во картинок, которые надо сгенерить, но и время генерации. А из этого надо делать вывод об аппаратной части, которая требуется. Иначе оптимизировать нечего, генерит и ладно, а какое время это заказчика (ТЗ) и исполнителя волновать не должно

К сожалению, именно в этой части ТЗ оставлены многоточия, которые я и пытаюсь разрешить.


Наконец-то отписался хостер. Сказал, что у них резиновые ВДС и они будут сами притормаживать процессы, и что мне нефиг над этим париться.

В этой связи пришла такая глупая идея, как думаете, оптимально или нет?

1. С помощью php генерировать shell-файл c подробными инструкциями для imagemagick
2. В этот-же файл и в БД сохранять адрес временной директории, куда надо положить результат
3. PHP запускает этот файл и естественным образом менее 30 сек. завершает свою работу, редирект на п. 4
4. PHP проверяет существование директории, если нет - ждем клиентом столько-то секунд и редирект на п.4
5. Если директория есть - выдаем результат и так далее

???

P.S. кстати, как в данном случае будет корректнее - все-таки exec(), system() или passthru()?

 

[Adelf]

Я конечн не знаю специфики, но если результат выдается человеку, то можно сразу выдать первые сделанные 20 например картинок.. остальные уже по мере генерирования... Хотя гадать бесполезно - тоже жду линк