Как определить параллелизм (потоки) при использовании shoryuken для фоновых заданий?

В моем приложении Ruby on Rails я использую shoryouken для фоновой обработки. В моем приложении много очередей sqs (6-7). Одна из очередей имеет 2000-3000 заданий, и работнику требуется около 3 часов для обработки этих 2-3 тыс. Заданий с параллелизмом по умолчанию, равным 25. Итак, исходя из того, какие факторы мы можем принять решение об увеличении параллелизма (а это число потоки для обработки заданий). Пожалуйста, прокомментируйте, если что-то неясно в вопросе.

Источник

2 ответа

Решение

Параллелизм по умолчанию равен 25, но его можно изменить, изменив shoryuken.yml конфигурации (см. ниже) или добавив аргумент параллелизма следующим образом: shoryuken -c {desiredCount}

concurrency: 25  # Update with your desired value.
delay: 25        # The delay in seconds to pause a queue when it's empty. Default 0
queues:
  - [high_priority, 6]
  - [default, 2]
  - [low_priority, 1]

Вам нужно будет проверить оптимальное значение для производительности, так как вы столкнетесь с узкими местами ввода-вывода и ЦП по мере увеличения числа параллельных потоков. Как только вы достигли оптимального значения для ваших экземпляров, вам нужно либо увеличить количество экземпляров, выполняющих это задание, либо обновить эти экземпляры.

Если вместо этого существует узкое место в вашей БД или другом ресурсе, вам необходимо соответствующим образом изменить его. (Скорее всего, не так, но ради тщательности)

РЕДАКТИРОВАТЬ: Оптимизация производительности

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

Это тот случай, когда вы легко можете задуматься над чем-то (опять же, переосмысление вещей является постоянной проблемой в процессе разработки). Просто измерьте соответствующие метрики (загрузка ЦП, использование памяти, количество выполненных заданий в минуту) и меняйте количество потоков до тех пор, пока вы не достигнете максимальной пропускной способности или не столкнетесь с узким местом.

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

Узкое место ввода / вывода может возникнуть, когда какие-либо ресурсы, которые вы читаете / пишете, не в состоянии удовлетворить ваши требования к процессору. Это включает системные ресурсы (память, дисковое пространство), производительность вашей базы данных (загрузка ЦП БД, ограничения на чтение / запись), а также другие API, с которыми вы соединяетесь. Емкость сети также является теоретическим узким местом, но если бы это было так, вы были бы достаточно большими, чтобы нанять кого-то с опытом в этой области. Поскольку существует так много разных способов, чтобы это произошло, единственный реальный способ выяснить, в чем заключаются узкие места, - это установить мониторинг.

Re: формула, краткий ответ таков: в этом случае нет ни одной формулы, которую вы могли бы использовать. Длинный ответ, вероятно, да, но вы получите оптимальное значение в процессе сбора всех значений, необходимых для его расчета.

РЕДАКТИРОВАТЬ 2: параллелизм, задержка и пропускная способность

Я понял, что забыл добавить еще один совет. Когда вы работаете с фоновыми задачами, которые пользователи не ждут, ваша пропускная способность (задания в единицу времени) - единственное, что вы хотите оптимизировать. Не оптимизируйте для индивидуального рабочего времени. Это также означает, что вы не можете профилировать текущую (и предположительно неограниченную) производительность и получать полезные данные, потому что узкие места / ограничения зависят от цели. Ограничения, которые существуют для пропускной способности, НЕ будут такими же, как ограничения, которые существуют для отдельного времени задачи.

(Технически говоря, ваш параметр параллелизма является вашим текущим ограничением)

Источник

Три основных фактора

  1. Количество ядер
  2. Тип задания - ввод / вывод или привязка к процессору
  3. Есть ли на сервере другое приложение или процесс?

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

Для задачи, связанной с вводом / выводом, требуется сравнительный анализ и вычисление времени ожидания для ввода / вывода, а затем вы можете выбрать оптимальное значение. Для грубой оценки, если у вас есть 4 ядра, чем для задачи, связанной с вводом / выводом, вы должны поддерживать максимум 8 потоков.

Если ваше приложение rails запущено на одном и том же компьютере, вам нужно уменьшить количество ядер.

Увеличение количества ядер не увеличит вашу производительность, если ваша система не поддерживает.

См. http://baddotrobot.com/blog/2013/06/01/optimum-number-of-threads/

Источник
Другие вопросы по тегам