Блог

Мое текущее приложение имеет статус около 5000 сетевых узлов в базе данных. Каждый узел должен обновляться поминутно, чтобы предоставлять текущий статус. Процесс обновления выглядит следующим образом:

1. Получить старую запись из базы данных, чтобы получить ее IP
2. Отправьте RPC на узел
3. Обновите запись базы данных возвращенными данными

Для этого я использую Laravel horizon, который предоставляет мне удобный планировщик заданий на основе redis. Каждую минуту cron получает все записи узла и отправляет каждую UpdateNode(id) задачу в планировщик.

С увеличением количества узлов мне также приходится постоянно увеличивать количество работников расписания. В настоящее время 60 потоков PHP отвечают только за обновление узлов, чтобы поддерживать выполнение цикла обновления.

Этот факт снова приводит к огромной проблеме с ресурсами (в настоящее время 80% оперативной памяти и 70% процессора на 40-долларовом DigitalOcean Droplet), что снова подводит меня к моим основным вопросам:

1. Является ли Laravel (или гораздо больше PHP) по-прежнему подходящим кандидатом для этой работы?
2. Возможно, я делаю что-то неправильно с точки зрения Laravel? Обычно получение записи в базе данных, отправка RPC и обновление записи новыми данными не должно быть большой проблемой.

// редактировать: Вот мой iostat :

// для всех, кого интересует вот проект:https://github.com/nknx-org/nknx-api Задание, о котором мы говорим, это https://github.com/nknx-org/nknx-api/blob/master/app/Jobs/UpdateNode.php

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

Вместо того, чтобы ваша единственная запланированная задача отвечала за отправку всех 5000 UpdateNode заданий для рабочих, вы могли бы разделить записи на фрагменты идентификаторов. Итак, ваша запланированная задача разбила бы 5000 записей, например, на блоки по 250 идентификаторов и отправила бы 20 новых DispatchUpdateNodeJobs($ids) заданий, каждое с массивом из 250 идентификаторов.

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

Однако, если вы говорите, что загрузка процессора высока из-за того, что все 60 ваших существующих работников находятся на одном сервере, то я думаю, вам просто нужно добавить еще один сервер, чтобы разделить работу. 60 PHP-процессов, каждый из которых использует 1% ЦП и ~ 25 МБ памяти, все равно будут использовать 60% ЦП и 1,5 ГБ памяти, избежать этого при таком количестве активных процессов невозможно.

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

В конечном счете, лучший вариант будет зависеть от того, каковы ваши текущие узкие места и как настроена система.

%user = 53% это одна задача = 1% * 4CPU = 4% это большой

Разделить вашу задачу

handle() — получать данные только в папку или redis

 file_put_contents("/path/to/response/nodes/".time()."_".$node->alias,$apiRequest->getBody());
  

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