Бинарный конвейер Википедии, с которым я экспериментирую, неплохо работает на EC2 или ECS, но для бесперебойной работы требуется 9 процессоров (преобразование XML в JSON). Что, если я распространяю его и запускаю каждый рабочий процесс на ECS?

Цель

Я хочу сократить общее время выполнения с 47 минут (ECS 4vCPU) и 19 минут (c5.2xlarge 8vCPU) до менее 10 минут. Я предполагаю, что мне нужно масштабировать по горизонтали, чтобы извлечь выгоду из многих одновременно выполняемых задач ECS.

Мастер / Рабочий

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

Где задача ECS в моем двоичном конвейере определяется следующим образом:

1-е исполнение

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

Изменения

Хорошо, что я обнаружил, что узким местом больше не ЦП, а FTP-серверы. Теоретически я мог бы увеличить количество подключений к каждому FTP-серверу (из-за разных публичных адресов контейнеров ECS), но это было бы неэтично. Я бы предпочел отделить загрузку по FTP от ее дальнейшей обработки.

Владелец

Мастер-код был скорректирован для последовательного вызова двух контейнеров. Каждый вызов регулируется специальными регуляторами.

Рабочие

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

2-е исполнение

Согласно следующей панели, выполнение заняло около 10 минут и использовало 54 контейнера. Загрузка по FTP по-прежнему занимала большую часть времени, но обработка могла выполняться быстрее. Основной сценарий должен запускать 15 дочерних процессов, что увеличивает нагрузку на драйвер. Кроме того, вращающиеся контейнеры добавляют дополнительное время моему эксперименту.

Код здесь.