Измерение производительности
Проблема больших приложений
Начнем с введения в проблематику. Что такое большое приложение? Может это то приложение, которое обрабатывает около 20k rps? Или же это приложение, которое обрабатывает свыше 100k rps? Ответ заключается в том - что приложение большое, когда базовый функционал не справляется. То есть то, что написал ты.
Как отследить проблему?
Итак, мы поняли что написанный тобой код не справляется с нагрузкой и надо что-то делать. Начнем же думать. Первое что следует сделать, это понять, что именно доставляет тебе проблемы.
Проблема с БД
Очень часто на производительности сказывается БД. Однако это применимо к тем случаям, когда бд уже размером больше 1ТБ, если же она имеет размер 10ГБ, то проблема явно на твоей стороне. Давай изучать.
Начнем с метрик БД. Открой утилиту для исследования (если это postgreSQL, то pgadmin тебе в помощь). Если же ты хостишь БД где-то в облаке, то открой панель мониторинга и посмотри по нагрузке, что и как. Возможно у тебя нагрузка под 100% потому что ты забыл создать индексы. Или же у тебя в рамках одного метода идет 15 запросов к бд. Также лишним не будет добавить кеширование. Кешировать стоит часто повторяющиеся данные, которые являются статичными и не будут часто изменяться. В данной ситуации идет реализация кеша на уровне базы данных (есть так же на уровне приложения).
Если же база данных имеет очень большой размер, то тогда в процессах оптимизации может помочь процесс репликации.
Репликация - дробление бд с поддержкой консистентности данных. Этот процесс будет рассмотреть в отдельной статье, для более глубокого погружения в этот сложный процесс.
Проблема платформы
Мы говорим в первую очередь про Nest, так что от него и будем отталкиваться. В чем будет заключаться его проблематика? Да все так же в плохо написанном коде. Про лишние запросы к бд, про то, как ты кешируешь данные. Да, кеш является очень даже полезной штукой. С помощью кеша, можно сократить нагрузку на приложение и на БД.
К основным настройкам кеша можно отнести его TTL (Time To Leave). Это тот промежуток, в котором будет существовать кеш.
Если же говорить о реальном кейсе, то мы накатим redis на railway (в бесплатной версии там US регион), то тогда скорость ответов от бэкенда с кеша достигнет в среднем 90ms (напоминаю, сервак находится в USA).
Средства мониторинга
Для мониторинга состояния всего приложения, можно использовать Grafana (для визуализации) и Prometheus для сбора метрик. Картинку прикрепил ниже
Стоит обратить внимание, что все эти показатели, которые представлены на картинке можно кастомизировать и добавлять те, что нужны именно тебе.
Наиболее полезными метриками могут быть:
Количество запросов в секунду на определенный роут. В случае DDoS атаки можно отследить, на какой роут идет атака, ну если он единичный конечно.
Количество подключений от пользователей. Отслеживать количество активных пользователей на момент времени.
Состояние нагрузки CPU, RAM, GPU etc.
Также для мониторинга самой ноды можно использовать clinic. Он создает html страницу с метриками за определенный промежуток. Можно накатить и запускать это как на проде, так и локально. Однако для нагрузки приложения локально, следует использовать утилиту autocannon. Она позволит создавать заданное кол-во запросов за единицу времени на определенный маршрут.
Выводы
В данной статье были рассмотрены основные уязвимые места приложения, а так же способы мониторинга и борьбы с ними.
В данной теме я не поднимал тему шардирования, деления на микросервисы и тд, так как это будет затронуто позже, в отдельной статье.