Должен ли я использовать очереди сообщений для этого?

Question

У меня есть приложение PHP, которое в настоящее время имеет 5 тыс. Пользователей и будет расти в обозримом будущем. Раз в неделю я запускаю скрипт, который:

• выбирает всех пользователей из базы данных
• перебирает пользователей и выполняет некоторое обслуживание для каждого (включая добавление новых записей в БД)

В последний раз, когда этот скрипт запускался, он только обработал 1400 пользователей перед тем, как умереть из-за 30-секундной ошибки максимального времени выполнения. Одно из решений, о котором я подумал, состояло в том, чтобы основной сценарий по-прежнему выбирал всех пользователей, но вместо выполнения самого процесса обслуживания он выполнял бы асинхронный вызов cURL (1 для каждого пользователя) для нового сценария, который будет выполнять обслуживание для этого конкретный пользователь.

Меня беспокоит то, что вызовы 5k + cURL могут привести к остановке сервера. Это можно исправить, используя очередь сообщений вместо вызовов cURL? У меня нет опыта его использования, но из того, что я прочитал, кажется, что это может помочь. Если да, то какую систему очередей сообщений вы бы порекомендовали?

Некоторая справочная информация:

• это проект Symfony, использующий Doctrine в качестве моего ORM и MySQL в качестве моей БД
• сервер является машиной Windows, и я использую планировщик задач Windows и wget для автоматического запуска этого сценария один раз в неделю.

Любые советы и помощь приветствуются.

Answer 1

Несколько идей:

1. Увеличение срока выполнения сценария - set_time_limit()
   Не идите за борт, но более 30 секунд будет началом.
2. Отслеживание поддержки пользователей
   Возможно, добавьте поле для каждого пользователя, last_check, и установите в этом поле дату / время последнего успешного действия "Поддержание", выполненного для этого пользователя.
3. Обработка меньших партий
   Лучше запускать меньшие партии чаще. Думайте об этом как о PHP-эквиваленте «всех ваших яиц в более чем одной корзине». С указанным выше полем last_check было бы легко идентифицировать тех, у кого самый длинный период с момента последнего обновления, а также установить порог частоты их обработки.
4. Чаще бегать
   Установите cronjob и обработайте, скажем, 100 записей каждые 2 минуты или что-то в этом роде.
5. Журнал и обзор вашей производительности
   Иметь лог-файлы и записывать статистику. Сколько записей было обработано, сколько времени прошло с момента их последней обработки, сколько времени занял сценарий. Эти метрики позволят вам настроить размеры пакетов, настройки cronjob, сроки и т. Д., Чтобы гарантировать, что максимальные проверки выполняются стабильно.

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

Answer 2

Если возможно, я бы сделал запланированное задание (задание cron), которое выполнялось бы чаще, и использовал бы LIMIT 100 (или другое число) для одновременной обработки ограниченного числа пользователей.

Answer 3

Почему бы вам не использовать идею cURL, но вместо того, чтобы обрабатывать только одного пользователя для каждого, отправьте группу пользователей одному, разделив их на группы по 1000 или около того.

Answer 4

Как насчет увеличения лимита времени выполнения PHP?

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

Answer 5

Рассматривали ли вы изменение своей логики для фиксации изменений при обработке каждого пользователя?Похоже, вы выполняете одну транзакцию для обработки всех пользователей, что может не потребоваться.