Достижение пределов Apache Storm

Мы пытаемся реализовать веб-приложение с помощью Apache Storm.

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

Мы используем Cassandra в качестве приемника его возможностей записи.

Однако мы уже превысили требование 8 ms, мы находимся в 100ms.

Мы постарались минимизировать размер буферов (Disruptor buffers) и хорошо сбалансировать топологию, используя параллелизм болтов.

Но мы все еще в 20ms.

С 4 рабочими (8 ядер / 16 ГБ) мы находимся на уровне 20k TPS, что все еще очень мало.

Есть ли предложения по оптимизации или
мы просто достигли пределов Apache Storm
(пределов Java)?


stream-processing apache-storm low-latency
person Radhwane Chebaane    schedule 10.07.2015    source источник
comment
Можете ли вы объяснить мне, почему вам нужна задержка 10 мс? предполагается, что другая система будет читать Cassandra и что-то делать с результатом?   -  person SQL.injection    schedule 10.07.2015
comment
Ну, лучше всего то, что storm отправляет результат на удаленный сервер. В противном случае это можно было бы сделать, имея другой внутренний сервер, который считывает данные с Cassandra и отправляет их на этот удаленный сервер. Но эти данные уже должны быть в Casandra, максимум через 10 мс после получения запроса.   -  person Radhwane Chebaane    schedule 10.07.2015
comment
тогда у вас есть ответ, storm должен отправлять данные непосредственно в систему, которая должна их потреблять (и в cassandra, если вы хотите сохранить их по другим причинам). Это позволит вам сократить один шаг в вашей критически важной системе с низкой задержкой.   -  person SQL.injection    schedule 10.07.2015
comment
Общая задержка между получением запросов Storm и их отправкой составляет уже более 20 мс при ограниченной пропускной способности. Нам нужно достичь 100 TPS с задержкой менее 10 мс для 99% кортежей.   -  person Radhwane Chebaane    schedule 10.07.2015
comment
@RadhwaneChebaane Прошла ли ваша архитектура проекта формально технико-экономическое обоснование? Я пришел из обработки потока транзакций, где счет идет наносекунды. Задержка около 10 мс расслабляет, если была разработана правильная архитектура. Плохая архитектура пострадает, задушит и снизит поток и производительность даже на таких низкоинтенсивных уровнях TPS   -  person user3666197    schedule 04.12.2015
comment
С тех пор проект получил дальнейшее развитие, но проблема не была полностью решена с помощью Apache Storm. Причина в том, что Lmax ожидает, а стратегия буферов является дорогостоящей и требует много времени обработки в нашем случае использования. Более того, блокировка соединений с приемниками (внешняя база данных) плохо управляется при высоком уровне параллелизма.   -  person Radhwane Chebaane    schedule 08.12.2015

Ответы (2)


arrow_upward
2
arrow_downward

Я не знаю, какую платформу вы используете, но в C++ 10ms — это вечность. Мне кажется, вы используете неправильные инструменты для работы.

При использовании C++ выполнение некоторого локального запроса занимает меньше микросекунды.

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

Вы должны найти узкое место.

  1. Is it I/O?
  2. Это процессор?
  3. Это пропускная способность памяти?
  4. Это время доступа к памяти?

После того, как вы нашли узкое место, вы можете улучшить его, асинхронизировать и/или умножить (= распараллелить).

person BitWhistler    schedule 20.07.2015
comment
Это очень интересный совет, но он не выглядит как полное решение. Знаете ли вы какие-нибудь альтернативы Apache Storm (или любой системе распределенной потоковой передачи с открытым исходным кодом), которые очень хорошо справляются с вводом-выводом? - person Radhwane Chebaane; 08.12.2015

arrow_upward
2
arrow_downward

Существует компромисс между низкой задержкой и высокой пропускной способностью.

Если вам действительно нужна высокая пропускная способность, вы должны полагаться на пакетную настройку размера буферов или использование Trident.

Попытка избежать передачи кортежей другим рабочим процессам помогает снизить задержку. (localOrShuffleGrouping)

Пожалуйста, не забывайте следить за GC, который вызывает остановку мира. Если вам нужна низкая задержка, ее следует свести к минимуму.

person Jungtaek Lim    schedule 12.07.2015
comment
Я уже пробовал эти варианты, минимизировал буферы LMAX и использовал LocalGrouping. Пакетная обработка приведет к дополнительной задержке, поэтому ее следует избегать. GC является основной проблемой, поскольку он так сильно мешает, и мы не можем его контролировать. - person Radhwane Chebaane; 13.07.2015
comment
Если рабочие процессы находятся под полным сборщиком мусора дольше, чем ожидалось, дальнейшая настройка не имеет смысла. Пожалуйста, настройте сборщик мусора, чтобы решить проблему с полным сборщиком мусора, прежде чем решать другие проблемы. - person Jungtaek Lim; 13.07.2015
comment
Мы обнаружили, что Storm плохо адаптирован к миллисекундным задержкам из-за стоимости передачи болтов. - person Radhwane Chebaane; 08.12.2015