Приложение ExpressJS, которое получает около 70 запросов в секунду - низкая производительность Cassandra

Это не вопрос, связанный с кодом, а скорее с производительностью сервера и вещами, которые я должен проверить. Итак, у меня есть сервер ExpressJS, который подключен к базе данных cassandra (1 начальный узел и 2 узла в 1 кластере, всего 3 узла). API работает на том же сервере, что и начальный узел cassandra db. У меня всего 3 сервера в локальной сети.

Итак, структура выглядит так:

сервер 1 с запущенным API и начальным узлом cassandra. сервер 2, на котором работает узел cassandra. сервер 3, на котором работает узел cassandra.

Каждый сервер имеет 8 ГБ оперативной памяти и 2,5 ГГц ЦП.

По умолчанию каждую секунду поступает около 70 запросов, что делает следующее:

1) Вызывает функцию, которая считывает данные из таблицы из кассандры (используя материализованное представление). 2) Читает другую таблицу из cassandra db (используя материализованное представление). 3) Отправляет данные в третью таблицу в кассандре.

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

Пропорциональная разница между функцией, вызываемой каждую секунду, составляет около 30 раз, когда вызывается функция 1 (которая выполняет 2 чтения и 1 запись), и около 40 раз вызывается функция 2 (которая выполняет 1 чтение и 1 запись).

Все бы ничего, но латентность запросов время от времени скачет, иногда проходит в районе 10мс, но каждые 5 - 10 секунд доходит до 3-30 секунд. Также кассандра кажется нестабильной - в период, когда время запроса составляет 3-30 секунд, кассандра, похоже, истекает по тайм-ауту для некоторых запросов.

Что я должен проверить в первую очередь? Нужны ли мне дополнительные узлы и как я могу выяснить, достаточно ли у меня узлов для объема данных, отправляемых в cassandra db? Должен ли я отделить API от узлов cassandra - таким образом, держать сервер API на отдельном сервере, например, на сервере 4?


person Patiss    schedule 31.05.2019    source источник
comment
Возможно, вам потребуется проверить, находится ли узкое место в кластере cassandra или в экспресс-приложении. Вы можете самостоятельно провести стресс-тестирование своего кластера cassandra с помощью стресс-инструментов cassandra: docs .datastax.com/en/cassandra/3.0/cassandra/tools/   -  person Masum    schedule 01.06.2019


Ответы (1)


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

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

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

В моем ответе много предположений, так как в структуре и схеме вашей таблицы много неизвестных; вы можете лучше понять, если включите трассировку, в нашем случае мы получили хорошие результаты с openzipkin, как объяснено TLP

person Carlos Monroy Nieblas    schedule 01.06.2019