Приложение ExpressJS, которое получает около 70 запросов в секунду - медленная производительность Cassandra - PullRequest
0 голосов
/ 31 мая 2019

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

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

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

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

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

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

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

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

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

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

1 Ответ

0 голосов
/ 01 июня 2019

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

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

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

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

...