Laravel по-русски

IgorVR

Сообщений: 6

Многопоточность, кто сталкивался?

Ищу совета.
Дано: несколько парсеров, http — клиентов.
Задача: требуется запускать их параллельно , получать от каждого результат парсинга, как можно быстрее. Если парсер работает больше какого—то времени, то завершать его — выкидывая по этому парсеру ответ об неудачи.

Думаю сделать это очередями Laravel, но боюсь за скорость ответа. Так как парсеры должны вернуть ответ пользователю как можно быстрее.

i3bepb +4

Откуда: Екатеринбург

Сообщений: 20

Re: Многопоточность, кто сталкивался?

Думаю сделать это очередями Laravel, но боюсь за скорость ответа.

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

Вообще я бы ответ получал через websocket. Например перешли на страницу где надо выводит ответ/результат парсеров, в очередь кинулись несколько задании на парсинг и слушатели, после того как выполнили через websocket отдали бы ответ/результат парсинга на фронт. А тем временем на странице какой-нибудь loading... с сообщением, что идет обработка.

Ну а скорость обработки будет зависит:

1. От того как часто проверяет слушатель наличие задании в очереди, есть такой параметр sleep, что-ли, он по умолчанию 1, т.е. слушатель засыпает на секунду, таким образом снижается нагрузка на железо, но если надо как можно быстрее преступить к обработки и есть ресурсы можно поставить 0.

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

IgorVR

Сообщений: 6

Re: Многопоточность, кто сталкивался?

Огромное спасибо.
Да, тоже так думаю и в принципе пишу, думаю так сделать:
1. Каждый HTTP клиент положить в очередь.
Для скорости, очередь положить в Redis.
2.Очередь будет отрабатывается и по мере прогресса в отдельный параметр Redis ключа - класть результат.
3. Ключи редис - сделать с временем жизни, что бы не хлама не разбирать.
4. Фронт будет дергать бек и смотреть, выполнились ли все задания.
5. Думаю, что если какой-то клиент подвиснет, то результат можно забрать по таймауту. Тоже решаемо.

Вопрос элегантности и работоспособности моей модели остаётся открытым.