Yii Framework

Здравствуйте!

Никогда не сталкивался с очередями и сразу такой вопрос: Может ли очередь заменить CRON TAB в целях сохранения ресурсов сервера?
А теперь описание: Есть некоторый cron action выполняющийся с периодичностью, кажем раз в 6 часов, сжирает он довольно таки приличное количество ресурсов (ЦПУ, ОЗУ) из-за некоторым клиентам, обращающиеся за данными, просто не будет ответа а того и вообще сервер может лечь не на долго. В этом и вопрос, можно ли с очередями мягко ограничить выполнение задания в плане ресурсов пусть работает пол часа, но в фоне, чем 5 минут и все грохает...

Операция, кстати, нечто вроде парсинга, примерно 200МБ файл xml грузится в память, от туда уже просто, реально много запросов к БД.

Очереди используются, как правило, для отложенного выполнения, дабы основной процесс не ждал выполнения чего-либо.
Например, зарегистрировался пользователь, и письмо отправилось не сразу, а отправилось в очередь.
Тем самым, клиент не ждёт, пока уйдёт письмо, а сразу видит "Вы зарегистрированы".

Или, например, пользователь добавил отзыв.
И надо пересчитать количество отзывов или рейтинг статьи по отзывам.
Так вот, отзыв в базу добавляется сразу, а в очередь отправляется событие на пересчёт количества/рейтинга.
Тем самым, пользователь, опять же, не ждёт, пока выполнится что-то, что может выполниться и потом.

Что касается XML - его не надо грузить весь в память, иначе что делать с файлами больше 10 Гб? А больше 50 Гб?
Файл надо читать побайтово, а не через Xml DOM Parser.
Например, XMLReader.

В базу вставлять не поштучно, а сначала складывать в буфер, а потом batchInsert() этого буфера каждые, скажем, 1000 записей.

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

SiZE писал(а): ↑2019.03.06, 22:03 не понятно, кто и куда и зачем обращается

Обращаются пользователи (клиентские приложения), жрет ресурсы CRON TAB (каждые 6 часов) и так бывает, что памяти может не хватить для ответа некоторым клиентам да и вообще, сам CRON может крякнуться и унести собой всю виртуалку, т.е минус 1 хост - вот сюда и может попасть клиент и ничего не получить, тем самым крякнется уже у него на устройстве (приложение) вот такие да дела. Но на самом деле это излишние детали...

А что хотелось бы получить в идеале: такую схему, при котором планировщик или очередь или еще что-то невиданное да неслыханное (мною) могло бы само "думать и решать" типа: "хозяин поставил планку в 1ГБ ОЗУ и ЦПУ не выше 25% в нагрузке, моя активность уже на пике, а ресурсов не хватает, пожалуй подожду-ка я пока кто-нить не освободит ресурсы" Вот так как-то, но это, думаю, утопия

frid-karatel писал(а): ↑2019.03.06, 17:26
Что касается XML - его не надо грузить весь в память, иначе что делать с файлами больше 10 Гб? А больше 50 Гб?
Файл надо читать побайтово, а не через Xml DOM Parser.

там вообще simplexml_load_string

frid-karatel писал(а): ↑2019.03.06, 17:26 В базу вставлять не поштучно, а сначала складывать в буфер, а потом batchInsert() этого буфера каждые, скажем, 1000 записей.

В общем там такая "фиг победишь" логика, я насчитал 4 вложенных цикла где вызывается метод Model::save().
А batchInsert будет выйгрышь в том, что будет 1 обращение к БД вместо 1000? UPD: и думаю не только, получается 1000 (условно) объектов создается при итерациях в О(4), омг...

Спасибо за пояснение очередей на прекрасных примерах!)

Может на чистом SQL переписать?

someweb писал(а): ↑2019.03.07, 09:40 Может на чистом SQL переписать?

На чистом SQL парсинг XML файла?

Нет, я про это

В общем там такая "фиг победишь" логика, я насчитал 4 вложенных цикла где вызывается метод Model::save().

worldof писал(а): ↑2019.03.07, 09:12 Но на самом деле это излишние детали...

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

Запускайте Cron на отдельной виртуалке, куда клиенты не ходят.