Kubernetes / Node MySQL - Параллельные запросы экспоненциально замедляются и вызывают сбой модуля

Question

Kubernetes / Node MySQL - Параллельные запросы экспоненциально замедляются и вызывают сбой модуля

0

У меня есть приложение Node/React, использующее кластер kubernetes для развертывания и бэкэнд MySQL. Я обнаружил, что при одновременном одновременном прохождении одного и того же маршрута каждый последующий запрос становится значительно медленнее, а для некоторых маршрутов, где нагрузка данных немного больше (например, одна страница возвращает 330 строк MySQL), запросы приводят к сбоям в работе кубернетов запрос истекает. Это вызывает ошибки сервера и делает сайт непригодным.

Ниже приведены результаты тестирования ab с 100 запросами (10 одновременных): Percentage of the requests served within a certain time (ms) 50% 711 66% 850 75% 1105 80% 1199 90% 1562 95% 1763 98% 1831 99% 2102 100% 2102 (longest request)

Аналогичный запрос на странице загружает больше данных: всего 10 запросов (10 одновременных): The timeout specified has expired (70007)

Может ли кто-нибудь предположить, почему стручки рушится и как предотвратить это? Честно говоря, я не чувствую, что 330 рядов данных очень много, даже с 10 одновременными запросами.

Спецификации кластера должны быть подходящими: n1-standard-1 (1 vCPU, 3.75 GB memory) Total cores 3 vCPUs Total memory 11.25 GB n1-standard-1 (1 vCPU, 3.75 GB memory) Total cores 3 vCPUs Total memory 11.25 GB

Что также странно, что у меня есть 3 модуля для каждого компонента приложения; интерфейс, шлюз и бэкэнд. Только интерфейсные контейнеры рушится - я бы подумал, если что-нибудь, что бэкэндовые стручки должны потерпеть крах, поскольку это те, которые обрабатывают вызовы БД.

Alaan 06 март 2018, в 20:33

Источник

1

Может быть, вы достигаете предела оперативной памяти на nodejs
Andrew 06 март 2018, в 19:03

Теги:

mysql

node.js

kubernetes

concurrency

1 ответ

Ещё вопросы

Может быть, вы достигаете предела оперативной памяти на nodejs

Alaan · Answer 1 · 2018-03-07T12-37-00.000Z

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

Хотя для запроса потребовалось незначительное количество времени для обработки (53 мс), результаты, отправляемые обратно, содержали каждый столбец каждого объекта объединения (т.е. Если я запросил таблицу с тремя объединениями, я получил 4 столбца столбцов в ответе). Сам по себе это прекрасно, однако интерфейс и шлюз использовали GraphQL, который, казалось, не мог справиться с обработкой такого большого количества данных одновременно.

Резолюция состояла в том, чтобы перестроить запрос таким образом, чтобы были восстановлены только требуемые столбцы/строки (это заняло количество строк до двух цифр)