LINUX.ORG.RU

Ресурсоемкие операции - стоит ли оформлять в отдельный сервис?


0

0

Пришел на сайт пользователь, залил картинку/программу/видео, которое надо обработать: для картинки нужно сгенерировать тумбинашку, архив просканить на вирусы, а видео перекодировать в FLV/3GP.

Как это лучше сделать? Обычно, простые операции делают прямо при обработке запроса, т.е. как только получили картинку - сразу ее ресайзим до тумбинашки/генерим дополнительные картинки. Аналогично со сканированием на вирусы. А вот если нам залили большую картинку (jpeg на 20 метров при распаковке может сожрать 1-2 гигабайта оперативы), или прислали большой архив, то операция может быть довольно длительной, а в результате юзер отвалится по таймауту. А если будет несколько таких запросов, то тут вообще сервер ляжет.

Появилась идея: отвязать процесс преобразовывания/проверки от основной обработки запроса. Сделать отложенную операцию, как это делают при перекодировании видео: создается "задание" на работу, а отдельный скрипт-сервис (демон) по мере возможности выполняет задания. Пока задание не выполнено - пользователю выводится "подождите", или "скоро будет".

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

На стороне клиента показывать "подождите", к примеру, через 2 сек после начала операции.
Теперь сервер. Если на него будет идти большая нагрузка, то, безусловно, нужно планировать распределенную систему. Демон, который выполняет задания в один поток, идет в попу, поскольку у нас более одного нетерпеливого клиента. Демон должен работать в несколько потоков и даже на нескольких машинах, так что можно будет простые задания выполнять в пределах одного компа, а более сложные отправлять на другой.

ShprotX
()
Ответ на: комментарий от ShprotX

> На стороне клиента показывать "подождите", к примеру, через 2 сек после начала операции.

В том то и дело, что _очень_ бы не хотелось этого делать (аки слушать вопли "выбросте свой тормозной движек, поставте ****"), когда нагрузка минимальна.

> Демон, который выполняет задания в один поток, идет в попу, поскольку у нас более одного нетерпеливого клиента

Но тогда у пользователей появится шанс положить сервер, когда все они ломануться что-то тяжежелое обрабатывать. Тут только кластеризацию выигрываем, более ничего (идея такая, что на каждой машине кластера есть свои демоны, которые сообщают степень загруженности машины, из которой выбирается наиболее "свободный", которому и отдается задание (балансировка), но сами демоны по прежнему работают в порядке очереди в 1-2 потока, дабы не допускать ахтунга)

EmStudio
() автор топика

Проверить размер картинки, загруженность сервера эта входные данные для функции цели... оптимизируем по времени ожидания для всех клиентов... открываем книгу таненбаума читаем про планировщики реализуем что-то похожее... самым хитрым пишем... "Подождите слишком большой файл идёт обработка"

dimon555 ★★★★★
()

>Дык вот, насколько оправдано такое отвязывание?

отвязывание безусловно оправдано ибо уже сейчас виднеются вершины будущего кластера.

>Не будет ли резкой потери производительности, особенно на мелких картинках?


напиши, проверь. для мелочи можно и находу все сделать - почему бы и нет? впрочем, преждевременная оптимизация - суть зло.

generatorglukoff ★★
()

(самый простой вариант) Складывай необработанные данные в отдельную папку и по крону запускай обработку. Про flock(1) не забудь. Заодно и приоритет обработчику можно назначить и кол-во одновременных потоков и всякие ionice.

А те кто сразу конвертируют файлы в апаче, да ещё и за nginx-ом и при небольшом MaxClients потом сильно страдают под нагрузкой :).

true_admin ★★★★★
()

> Не будет ли резкой потери производительности, особенно на мелких картинках?

отвязывание делаем только на больших картинках / видеофайлах. очевидно же.

isden ★★★★★
()
Ответ на: комментарий от EmStudio

> В том то и дело, что _очень_ бы не хотелось этого делать (аки слушать вопли "выбросте свой тормозной движек, поставте ****"), когда нагрузка минимальна

Если клиент ждет уже >2 секунд, то это повод попросить его подождать. А лучше, чтобы он в висящую страничку все это время смотрел, да?

ShprotX
()

Короче, получается так:

if(-s("file.jpg.zip.avi")<_маленький_размер_){

processNow("file.jpg.zip.avi");

} else {

daemonAddQuery("file.jpg.zip.avi");

sleep 2;

if(!checkDaemonResponce){

print "Абажди немнога, пожмакай f5, ибо оно долго работает";die;

}

}

EmStudio
() автор топика
Ответ на: комментарий от EmStudio

> print "Абажди немнога, пожмакай f5, ибо оно долго работает";die;

тут можно прикрутить клевый вебдванольный прогрес-бар с аяксом =)

isden ★★★★★
()

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

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

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

И тут имеется проблема. Как определить, насколько загрузит файл систему? Для jpeg этот разброс может составлять сотни раз при одинаковом размере файла. Так что про это не следует забывать.

ShprotX
()
Ответ на: комментарий от ShprotX

можно ещё смотреть на размер картинок и длительность видеороликов с их размером для оценки. На оценку тоже потребуется время :).

true_admin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.