К оценке производительности микросервисного взаимодействия в веб-фреймворках

Моничев Иван Дмитриевич ORCID: 0009-0002-7073-2410 магистрант; Факультет Программной Инженерии и Компьютерной Техники; Национальный исследовательский университет ИТМО 197101, Россия, г. Санкт-Петербург, Петроградский р-н, Кронверкский пр-кт, д. 49 Monichev Ivan Dmitrievich Graduate Student; Faculty of Software Engineering and Computer Technology; ITMO National Research University 197101, Russia, St. Petersburg, Petrogradsky district, Kronverksky ave., 49 id.monichev@gmail.com Черяев Александр Сергеевич ORCID: 0000-0001-9892-4196 магистрант; Факультет Программной Инженерии и Компьютерной Техники; Национальный исследовательский университет ИТМО Программист; ИТ отдел; Гинзбург И.И. 197101, Россия, г. Санкт-Петербург, Петроградский р-н, Кронверкский пр-кт, д. 49 Cheryaev Alexander Sergeevich Graduate Student; Faculty of Software Engineering and Computer Technology; ITMO National Research University Programmer; IT department; Ginzburg I.I. 197101, Russia, St. Petersburg, Petrogradsky district, Kronverksky ave., 49 sasha10131310@gmail.com Государев Илья Борисович ORCID: 0000-0003-4236-5991 кандидат педагогических наук доцент; Мегафакультет компьютерных технологий и управления; Национальный исследовательский университет ИТМО 197101, Россия, г. Санкт-Петербург, Петроградский р-н, Кронверкский пр-кт, д. 49 Gosudarev Ilia Borisovich PhD in Pedagogy Associate Professor; Megafacultet of Computer Technology and Management; ITMO National Research University 197101, Russia, St. Petersburg, Petrogradsky district, Kronverksky ave., 49 goss@itmo.ru

Жуков Николай Николаевич ORCID: 0000-0002-5641-1613 кандидат физико-математических наук преподаватель; Мегафакультет компьютерных технологий и управления; Национальный исследовательский университет ИТМО 197101, Россия, г. Санкт-Петербург, Петроградский р-н, Кронверкский пр-кт, д. 49 Zhukov Nikolai Nikolaevich PhD in Physics and Mathematics Lecturer; Megafacultet of Computer Technology and Management; ITMO National Research University 197101, Russia, St. Petersburg, Petrogradsky district, Kronverksky ave., 49 nnzhukov@itmo.ru

ВВЕДЕНИЕ

Современные веб-приложения всё чаще строятся на базе микросервисной архитектуры, которая обеспечивает независимое развитие и масштабирование компонентов системы. При проектировании таких решений возникает потребность в достоверной и сопоставимой оценке производительности серверных веб-фреймворков. При этом отсутствует единый стандарт оценки производительности микросервисного взаимодействия. Различия в организации экспериментов, сценариях нагрузки и способах измерения приводят к тому, что полученные данные сложно экстраполировать на реальные проекты и использовать при выборе технологического стека ^[1].

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

В исследовании рассматриваются три языка программирования вместе с характерными для них веб-фреймворками, применяемыми при построении микросервисных систем: для JavaScript – NestJS ^[2], для C# – ASP.NET Core ^[3], для Go – Gin ^[4].

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

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

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

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

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

МЕТОДИКА ПРОВЕДЕНИЯ ОЦЕНКИ ПРОИЗВОДИТЕЛЬНОСТИ МИКРОСЕРВИСНОГО ВЗАИМОДЕЙСТВИЯ

Для объективного сравнения производительности микросервисного взаимодействия в различных веб-фреймворках необходима методика, обеспечивающая воспроизводимость результатов и минимизирующая влияние внешних факторов. В настоящем исследовании проводится контролируемый воспроизводимый эксперимент, при котором варьируется только один независимый параметр – используемая технологическая платформа – при неизменности всех остальных условий ^[5].

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

1. Формирование единых условий проведения эксперимента.
2. Определение техник нагрузочного тестирования.
3. Выбор и формализация метрик производительности.
4. Проведение нагрузочного эксперимента и сбор метрик.
5. Анализ и интерпретация полученных результатов.

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

Согласно подходу к сравнительному анализу производительности веб-фреймворков, предложенной TechEmpower ^[6] критическими факторами достоверности результатов являются:

• архитектурная идентичность – исследуемые системы должны реализовывать идентичную бизнес-логику и архитектурные паттерны;
• изоляция окружения – контейнеризация или изолированный Linux-хост;
• статистическая значимость – достаточный объём измерений для получения репрезентативных результатов.

Также важно учитывать влияние особенностей реализации исследуемых веб-фреймворков. В различных языках программирования и программно-технологических средах используются отличающиеся механизмы доступа к данным, обработки входящих запросов и конфигурации серверной инфраструктуры, что способно оказывать значительное влияние на получаемые показатели производительности ^[7]. Для обеспечения сопоставимости экспериментов в ряде исследований, в частности в тестах организации TechEmpower ^[8], используются унифицированные условия: единый дистрибутив операционной системы, одинаковая система управления базами данных PostgreSQL и выполнение прямых SQL-запросов без применения ORM-библиотек и дополнительных абстракций.

Также важным аспектом является тип и внутренняя организация баз данных, поскольку разные СУБД по-разному обрабатывают операции чтения, записи, индексации и транзакций, что может влиять на время отклика сервисов и искажать результаты сравнения. Поэтому во всех трёх реализациях использовались одинаковые базы данных, которые перед каждым запуском тестов приводились к единому начальному состоянию: выполнялась очистка хранилища и перезапуск сервера, поскольку наличие накопленных данных и состояние кэшей СУБД напрямую отражаются на скорости обработки запросов и, как следствие, на общей производительности приложения ^[9].

Изоляция всех компонентов эксперимента также является ключевым фактором, поскольку в контейнерах Docker можно указать фиксированные параметры ресурсов и отслеживать их потребление с помощью сторонних инструментальных средств (например, Grafana и Cadvisor), что было бы проблематично реализовать без контейнеризации ^[10]. Такой подход обеспечивает воспроизводимость эксперимента, а также удобство в развёртывании экспериментальной среды.

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

Нагрузочное тестирование представляет собой метод оценки поведения программной системы при воздействии контролируемой вычислительной нагрузки ^[11].В контексте микросервисных архитектур нагрузочное тестирование преследует двойную цель. Во-первых, это определение пороговых характеристик производительности отдельных сервисов; во-вторых, выявление узких мест при межсервисном взаимодействии.

Согласно стандарту ISO/IEC 25010:2023 (Systems and software Quality Requirements and Evaluation) ^[12], производительность (performance efficiency) является одной из восьми ключевых характеристик качества программного обеспечения, включающей следующие аспекты:

• Time Behaviour – способность системы обеспечивать требуемое время отклика при заданной нагрузке;
• Resource Utilization – эффективность использования вычислительных ресурсов;
• Capacity – максимальная нагрузка, которую система способна обслуживать.

Нагрузочное тестирование позволяет количественно оценить эти характеристики в условиях, приближенных к реальным. Нагрузочное тестирование можно классифицировать по характеру нагрузки ^[13].

1. Равномерное тестирование под нагрузкой. Выражается постоянной нагрузкой в виде фиксированного количества виртуальных пользователей, которое продолжается от нескольких минут до часов. Проводится с целью определения средних характеристик производительности.
2. Стресс-тестирование. Выражается возрастающей нагрузкой в виде увеличивающегося количества виртуальных пользователей, тестирование проводится до достижения точки отказа, с целью определения пределов масштабируемости.
3. Тестирование пиковых нагрузок. Выражается резкими кратковременными увеличениями нагрузки в разные промежутки времени. Такое тестирование применяется для проверки устойчивости системы к всплескам трафика.
4. Тестирование стабильности. Выражается длительной и умеренной нагрузкой для выявления утечек памяти и деградации производительности. Тестирование проводится от нескольких часов до дней, с целью выявления проблемных вопросов долговременной эксплуатации.

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

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

Среднее время отклика. Усреднённый временной интервал между отправкой HTTP-запроса и получением полного HTTP-ответа.

,

где – момент начала отправки запроса, – момент получения последнего байта ответа. Показатель отражает общую производительность системы при стандартной нагрузке и выражается в миллисекундах.

Перцентили времени отклика. p-й перцентиль – значение, ниже которого находится процент измерений в упорядоченном множестве. Например, если p95 времени отклика равняется 500 мс, то это означает, что 95% запросов возвращались серверу быстрее 500 мс. Эта метрика позволяет выявлять существенные задержки, недоступные при усреднении, выражено в миллисекундах.

Запросов в секунду (RPS). Количество успешно обработанных HTTP-запросов (HTTP status code 2XX, 3XX) в единицу времени.

,

где – количество успешных запросов, – общее время теста. Она адекватно отражает пропускную способность системы.

Инструментальные средства для проведения нагрузочного тестирования предоставляют множество метрик и характеристик, однако в текущем исследовании наиболее интересными для эксперимента были выбраны описанные выше.

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

В настоящем исследовании рассматриваются два ключевых показателя использования вычислительных ресурсов: средняя загрузка CPU и потребление оперативной памяти.

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

В процессе мониторинга данные о загрузке CPU собирались при помощи системы сбора метрик, основанной на временных рядах. Для каждого Docker-контейнера регистрировался накопительный счётчик процессорного времени, фиксирующий общее количество секунд, в течение которых процессор выполнял инструкции контейнера к моменту времени t.

Для получения фактической загрузки CPU из этого счётчика вычислялась скорость его изменения во времени – аналог производной по времени. В рамках эксперимента для этих целей использовалась функция rate() системы мониторинга Prometheus, вычисляющая среднюю скорость роста накопленного счётчика за заданный временной интервал. В качестве интервала усреднения ∆t принималось 30 секунд после завершения каждого теста, что обеспечивало устойчивость и сопоставимость значений. Таким образом, интенсивность использования CPU для контейнера определялась выражением:

,

где и – значения накопленного процессорного времени контейнера в начале и конце интервала наблюдения. – длительность интервала усреднения (30 секунд).

Результирующее значение показывает, какую долю времени одно логическое ядро процессора было занято выполнением инструкций данного контейнера. Для оценки общей загрузки микросервисного приложения вычислялась сумма интенсивностей по всем контейнерам. Затем выполнялось нормирование на количество логических ядер процессора, что позволило выразить показатель в процентах.

Потребление оперативной памяти – метрика, отражающая средний объём оперативной памяти, занятый контейнерами микросервисного приложения в процессе выполнения нагрузки. Показатель используется для оценки ресурсной эффективности реализации и устойчивости приложения к утечкам памяти при длительном выполнении.

Заключительными этапами предлагаемой методики являются проведение нагрузочного эксперимента, сбор метрик производительности и последующий анализ полученных результатов.

Для каждого Docker-контейнера фиксировался текущий объём используемой физической памяти. Данные собирались с помощью системы наблюдения за временными рядами, обеспечивающей периодическую регистрацию значений данной метрики. Так как использование памяти может незначительно колебаться во времени, для получения усреднённого и устойчивого показателя применялось вычисление среднего значения по интервалу наблюдения. В рамках эксперимента для этого использовалась функция avg_over_time() системы мониторинга Prometheus, которая вычисляет среднее значение метрики на заданном промежутке времени. Интервал усреднения составлял 60 секунд после завершения теста. Для общей оценки потребления оперативной памяти вычислялась сумма по всем контейнерам, а затем полученное значение было выражено в мегабайтах.

ЭКСПЕРИМЕНТАЛЬНОЕ ПРИЛОЖЕНИЕ

В качестве экспериментального приложения в настоящем исследовании используется торговая платформа, включающая базовые операции взаимодействия между пользователями, заказами и платежами. Подобные системы характерны для сферы электронной коммерции (e-commerce) и позволяют анализировать поведение микросервисов в условиях нагрузочного тестирования. В рамках разработанного приложения выделяются следующие ключевые сущности:

• пользователь, оформляющий заказы;
• заказ, содержащий продукты и статус;
• платёж, подтверждающий завершение транзакции.

Эти сущности отражают реальные процессы в электронной коммерции и служат основой для проектирования микросервисов и их взаимодействия.

Взаимодействие микросервисов можно классифицировать на два подхода: синхронный и асинхронный. Каждый из этих подходов имеет свои особенности, преимущества и недостатки, которые определяются в контексте требований системы ^[14].

При проектировании приложения было принято решение использовать комбинированный подход к взаимодействию микросервисов, сочетающий синхронное и асинхронное взаимодействие. Синхронное взаимодействие осуществляется через API Gateway ^[15], который служит единой точкой входа для клиентских запросов и маршрутизирует их к соответствующим микросервисам по протоколу HTTP. Асинхронное взаимодействие реализовано с использованием брокера сообщений, который обеспечивает обмен событиями между сервисами без прямой зависимости между ними.

Схема микросервисной архитектуры приложения, построенная с использованием шаблона API Gateway, представлена на рисунке 1. Клиентское приложение взаимодействует с системой через единый входной пункт – API Gateway, который инкапсулирует внутреннюю структуру сервисов и маршрутизирует запросы к соответствующим микросервисам.

Рисунок 1 – Схема микросервисной архитектуры приложения

Архитектура включает следующие компоненты.

1. Сервис пользователей. Управляет данными пользователей и обращается к собственной базе данных. Сервис взаимодействует с остальной системой через API-шлюз, получая и отправляя запросы только через него.
2. Сервис платежей. Отвечает за обработку заказов и использует собственную базу данных. Все клиентские запросы к заказам проходят через API-шлюз, который перенаправляет их в сервис платежей.
3. Сервис заказов. Выполняет обработку платежей и взаимодействует с внешней частью системы напрямую через API-шлюз. Сервис передаёт события об изменении статуса платежа в брокер сообщений.
4. Брокер сообщений. Обеспечивает асинхронную доставку событий от сервиса заказов к сервису платежей, который подписан на соответствующую очередь и обрабатывает сообщения.

Созданная архитектура была воспроизведена на трёх веб-фреймворках: ASP.NET Core, NestJS и Gin. При этом ASP.NET Core реализует строго типизированный модульный подход с поддержкой контроллеров и внедрения зависимостей, NestJS предлагает аналогичную модульную структуру в экосистеме JavaScript, а Gin представляет лишь базовые средства маршрутизации и обработки HTTP-запросов и оставляет проектирование архитектуры на усмотрение разработчика.

ЭКСПЕРИМЕНТАЛЬНОЕ ОКРУЖЕНИЕ

В таблице 1 приведены характеристики тестовой платформы – компьютера, на котором были запущены Docker-контейнеры для обеспечения сопоставимых условий. Такой подход позволил изолировать окружение каждого микросервиса, исключая влияние внешних факторов: различия в системных зависимостях, настройках, версиях ОС, что в результате свидетельствует о лучшей воспроизводимости результатов исследования.

Таблица 1 – Характеристики тестовой платформы

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

Таблица 2 – Зафиксированные версии технологий

Запросы к микросервисам в синхронных сценариях направлялись через общий API Gateway, что эмулировало реальный маршрут REST-взаимодействия.

В ходе испытаний задействовались встроенные агенты мониторинга приложений, для минимизации их воздействия на результаты, мониторинг был ограничен сбором внешних метрик ответа и потребления ресурсов. Для этих целей применялись cAdvisor и Prometheus: первый собирал данные о загрузке процессора, использовании оперативной памяти и состоянии контейнеров Docker, а второй осуществлял агрегацию и хранение метрик, выполняя периодические запросы к cAdvisor и предоставляя результаты в виде временных рядов для последующего анализа.

Для оценки производительности были применены четыре типовых сценария, охватывающие как синхронное, так и асинхронное взаимодействие.

Сценарий 1 – получение одного элемента по идентификатору. В ходе его реализации выполнялся GET-запрос на получение одного экземпляра сущности по уникальному идентификатору. Сценарий моделирует типовую операцию чтения. При этом, однако, возможна межсервисная зависимость, например, обращение к другому сервису для получения дополнительной информации.

Сценарий 2 – получение списка элементов. Выполнялся GET-запрос на выборку списка сущностей с поддержкой пагинации. Данный сценарий позволил оценить производительность при передаче набора данных и нагрузку на базу данных и API Gateway.

Сценарий 3 – создание нового элемента. Выполнялся POST-запрос на создание новой сущности через API Gateway. Сценарий имитирует типовую операцию записи.

Сценарий 4 – асинхронное обновление статуса через брокера сообщений. Моделируется сценарий, в котором один микросервис отправляет на публикацию сообщение в очередь сообщений брокера.

Нагрузочное тестирование производилось с помощью специального инструментария k6, генерирующего HTTP-запросы к сервисам. В работе ^[16] был представлен сравнительный анализ наиболее популярных инструментальных средств для нагрузочного тестирования. Авторы считают необходимым отметить, что k6 обеспечивает высокую надёжность результатов, удобство написания тестов и стабильную генерацию нагрузки при большом количестве виртуальных пользователей. Средства k6 при этом демонстрируют низкую нагрузку на систему при выполнении сценариев.

Для имитации параллельных пользователей использовались 100 виртуальных клиентов (потоков), одновременно отправляющих запросы, что обеспечивало равномерную нагрузку на систему. Чтобы избежать одновременной отправки всех запросов и более реалистично распределить нагрузку, между последовательными запросами каждого виртуального пользователя была установлена задержка в 1 секунду. Каждый сценарий при этом запускался в 10 повторениях для повышения надежности результатов ^[17].

Полученные значения метрик усреднялись по всем повторениям перед занесением в итоговую таблицу. Многократное повторение с последующим усреднением метрик соответствует общепринятой методике получения статистически достоверных данных.

ЭКСПЕРИМЕНТ

Для оценки производительности микросервисов в проведённом эксперименте тестированию подверглись четыре ключевых сценария API для сервиса заказов: Update Order (обновление заказа), Get Order (получение одного заказа по ID), Get Orders (получение списка заказов) и Create Order (создание нового заказа). Каждый сценарий выполнялся в трёх реализациях (NestJS, Gin, ASP.NET) при аналогичных условиях нагрузки согласно установленной методологии.

Далее приведены сводные таблицы с результатами измерений по каждой метрике, а также соответствующие графики для наглядного сравнения веб-фреймворков NestJS, Gin и ASP.NET Core в каждом сценарии.

В таблице 3 и на рисунке 2 представлены результаты сравнения среднего времени отклика на запрос по четырём сценариям взаимодействия с сервисом заказов.

Таблица 3 – Показатели среднего времени отклика

Рисунок 2 – График среднего времени отклика

Полученные значения показывают, что микросервисы, реализованные с использованием Gin, демонстрируют наименьшее время отклика во всех сценариях – от 1,46 до 13,55 мс, что указывает на высокую эффективность реализации и низкие накладные расходы среды выполнения. ASP.NET Core показывает сопоставимые результаты – от 2,47 до 17,44 мс с незначительным увеличением задержек, сохраняя при этом стабильную производительность. Наибольшие значения времени отклика наблюдаются у NestJS – от 5,43 до 51,54 мс, что можно объяснить интерпретируемой модели выполнения JavaScript и дополнительной логики фреймворка. Таким образом, полученные данные подтверждают преимущество компилируемых языков Go и C# в задачах с высокой частотой запросов, где критичны скорость обработки и предсказуемость отклика.

В таблице 4 и на рисунке 3 представлены результаты сравнения времени отклика на уровне 95-го перцентиля (p95) по тем же сценариям взаимодействия с сервисом заказов.

Таблица 4 – Показатели отклика на уровне 95-го перцентиля

Рисунок 3 – График отклика на уровне 95-го перцентиля

Анализ данных показывает, что микросервисы, реализованные с использованием Gin, вновь демонстрируют наилучшие результаты – значения p95 варьируются от 3,83 до 27,87 мс, что говорит о высокой предсказуемости и равномерности производительности даже при нагрузке.

Фреймворк ASP.NET Core показывает немного большие значения – от 6,16 до 33,64 мс, сохраняя при этом стабильную динамику и умеренный разброс между средним временем и p95, что указывает на эффективное управление ресурсами и устойчивость к временным пикам нагрузки.

Наибольшие значения p95 характерны для NestJS – от 14,05 до 92,51 мс, что свидетельствует о более выраженных колебаниях времени отклика и меньшей стабильности под нагрузкой.

В таблице 5 и на рисунке 4 представлены результаты сравнения пропускной способности сервисов, измеренной в количестве обработанных HTTP-запросов в секунду (RPS).

Таблица 5 – Показатели скорости обработки запросов

Рисунок 4 – График скорости обработки запросов

Полученные данные демонстрируют, что в большинстве сценариев разница между фреймворками минимальна, и все три реализации обеспечивают высокую пропускную способность – значения находятся в диапазоне от 94 до 100 RPS, что свидетельствует о сопоставимом уровне эффективности при обработке запросов. Тем не менее, в сценариях, связанных с операциями записи (Create Order и Get Order), приложение, реализованное на Gin, демонстрирует наивысшие значения пропускной способности. Это может быть связано с архитектурными особенностями языка Go, ориентированного на эффективную обработку конкурентных задач и минимальные накладные расходы при выполнении сетевых операций.

В таблице 6 и на рисунке 5 представлены результаты сравнения средней загрузки центрального процессора (CPU %), зафиксированной при выполнении основных сценариев взаимодействия с сервисом заказов.

Таблица 6 – Показатели средней загрузки CPU

Рисунок 5 – График средней загрузки CPU

Средняя загрузка CPU в Go-реализации находится в диапазоне от 0,84 % до 5,32 %, что подтверждает эффективность компилируемого кода и оптимальный механизм планирования горутин.

Показатели ASP.NET Core от 1,74 % до 3,70 % также остаются низкими и стабильными, что соответствует оптимизации среды .NET JIT-компиляцией и хорошему управлению потоками.

NestJS показывает наиболее высокие значения – от 2,52 % до 9,25 %, что связано с интерпретируемой природой JavaScript и дополнительными накладными расходами событийного цикла Node.js при параллельной обработке запросов.

Полученные данные показывают, что микросервисы на ASP.NET Core и Gin демонстрируют наименьшую нагрузку на процессор, тогда как NestJS требует больше вычислительных ресурсов при обработке тех же запросов.

В таблице 7 и на рисунке 6 представлены результаты измерений потребления оперативной памяти (RAM, МБ) во время выполнения основных сценариев взаимодействия с сервисом заказов.

Таблица 7 – Показатели потребления оперативной памяти

Рисунок 6 – График потребления оперативной памяти

Среднее использование памяти для Go находится в диапазоне от 43,61 до 98,52 МБ, что соответствует лёгкой архитектуре фреймворка и эффективной работе сборщика мусора с малыми паузами.

Показатели ASP.NET Core варьируются от 307,96 до 451,61 МБ, отражая более нагруженную инфраструктуру среды выполнения .NET, которая выделяет больше памяти под служебные объекты и буферы ввода-вывода, но обеспечивает стабильную работу без утечек. Фреймворк NestJS демонстрирует использование в пределах от 271,42 до 338,66 МБ, что несколько ниже ASP.NET Core, однако выше, чем у Go. Повышенное потребление памяти связано с интерпретируемой моделью Node.js, большим количеством зависимостей и динамической типизацией JavaScript.

Данные показывают, что микросервисы, реализованные с использованием Gin, потребляют существенно меньше оперативной памяти по сравнению с NestJS и ASP.NET Core, что подтверждает компактность среды выполнения и отсутствие избыточных абстракций в Go.

Обобщая результаты проведённого эксперимента, можно сделать следующие выводы относительно производительности исследуемых веб-фреймворков.

Микросервисы, реализованные с использованием Gin, демонстрируют наилучшие показатели эффективности по совокупности ключевых метрик. Для них характерно минимальное среднее время отклика в диапазоне 1,46–13,55 мс, а также наименьшие значения 95-го процентиля (p95) — 3,83–27,87 мс. Кроме того, решения на базе Gin обеспечивают наиболее высокую пропускную способность, достигающую значений порядка 99 RPS, при низкой загрузке процессора (до 5,32%) и минимальном потреблении оперативной памяти (около 98,52 МБ).

Фреймворк ASP.NET Core показал сопоставимые результаты по задержкам и стабильности отклика, при этом обеспечивая умеренное потребление ресурсов. Средняя загрузка процессора – 1,74-3,70%, а использование памяти – приблизительно 308-452 МБ.

Реализация на NestJS продемонстрировала наибольшее среднее и p95-время отклика – до 92,51 мс и наиболее высокую загрузку CPU – до 9,25%, что объясняется интерпретируемой природой JavaScript, особенностями событийного цикла и дополнительной логикой фреймворка. Несмотря на это, NestJS сохраняет приемлемую пропускную способность и может быть оправдан для сценариев, где приоритетом является скорость разработки. Благодаря использованию JavaScript, веб-фреймворк особенно удобен для фронтенд-разработчиков, поскольку позволяет им без значительных трудозатрат осваивать серверную часть и реализовывать полный цикл веб-разработки в едином технологическом стеке.

ЗАКЛЮЧЕНИЕ

В ходе исследования было успешно проведено тестирование производительности веб-приложений, написанных на платформах Gin, ASP.NET Core и NestJS. Описана методика проектирования архитектуры веб-приложений для проведения тестирования производительности. Описаны техники тестирования времени отклика и потребления аппаратных ресурсов компьютера, формализованы оцениваемые показатели, метрики и способы интерпретации результатов тестирования.

На основе результатов исследования были сформулированы выводы по оценке производительности веб-фреймворков на базе микросервисной архитектуры. Они могут быть использованы исследователями для анализа производительности других технологий в различных сценариях нагрузочного тестирования.

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

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

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

Статья публикуется в одобренном рецензентами варианте (после получения последней положительной рецензии, рекомендующей рукопись к публикации) с исправлениями автора (внесенными им после получения предварительных рецензий, рекомендующих рукопись к доработке). Все рецензии (включая предварительные рецензии) опубликованы в открытом доступе непосредственно за текстом самой статьи. Все варианты авторских исправлений хранятся в депозитарии издательства и могут быть доступны по требованию уполномоченных организаций.
Прочитать все рецензии на эту статью

Результаты процедуры рецензирования статьи

Рецензия выполнена специалистами Национального Института Научного Рецензирования по заказу ООО "НБ-Медиа".
В связи с политикой двойного слепого рецензирования личность рецензента не раскрывается.
Со списком рецензентов можно ознакомиться здесь.

Рецензируемая статья посвящена проблеме методической оценки производительности микросервисного взаимодействия в веб-фреймворках.
Оценка производительности требует комплексного подхода, включающего анализ пропускной способности, задержек, использования ресурсов и распределённой нагрузки. Среди широко распространенных методов оценки можно назвать нагрузочное тестирование, тестирование взаимодействия и мониторинг латентности. В рецензируемой статье авторами сделан акцент на использование первых двух методов из перечисленных.
1) Предмет и объект исследования
К сожалению, во вводной части, автором не приводится четкого формулирования предмета и объекта исследования. В разделе «Экспериментальное приложение» сказано, что «в качестве предметной области в настоящей публикации рассматривается торговая платформа, включающая базовые операции взаимодействия между пользователями, заказами и платежами». У читателя может возникнуть вопрос: является или предметом исследования данный пример предметной области (торговая платформа), или он трактуется несколько иначе, шире?
Вместе с тем, автором однозначно и понятно определены цель и задачи исследования, что является положительным моментом.
2) Методология (методика) исследования
Предлагаемая методика основана на единой архитектурной модели. На наш взгляд, было бы правильным раздел статьи «Методика проведения эксперимента» переименовать в «Методика проведения оценки производительности микросервисного взаимодействия», поскольку проведение эксперимента является заключительным этапом реализации методики (задача № 3, сформулированная во Введении»). Также, было бы логичным представить этот раздел числовой последовательностью этапов (методической оценки).
3) Актуальность
Рецензируемая статья имеет актуальность, в том числе по причине того, что результатом оценки производительности могут быть выявление ошибок (например, каскадные задержки) в микросервисной архитектуре и формулирование рекомендаций по их устранению. Это позволит повысить масштабируемость программной системы в целом.
4) Научная новизна
Научная новизна проведенного исследования состоит в разработке унифицированной методики для сравнительного анализа производительности различных микросервисных веб-фреймворков с учётом метрик потребления вычислительных ресурсов. Заслуживает внимания акцент на сопоставимости результатов между различными языками в рамках микросервисной архитектуры.
5) Практическая ценность
В статье приведены в достаточно большом объеме материалы и результаты экспериментальной части исследования, на основе которой автором были сформулированы выводы по оценке производительности веб-фреймворков на базе микросервисной архитектуры. Следует согласиться с мнением автора о том, что они могут быть использованы «для анализа производительности других технологий в различных сценариях нагрузочного тестирования».
6) Стиль, структура и содержание
В целом, стиль изложения статьи  технический. Структура статьи характеризуется логикой изложения материала. Содержание статьи раскрывает решение задач, сформулированных автором во Введении.
7) Библиография
Библиография в общем отражает проблематику исследования и является достаточно современной (не устаревшей).
8) Выводы и интерес для читательской аудитории
Считаем, что данная статья может вызвать интерес у определенного круга читательской аудитории. Отмеченные рецензентом замечания носят по большей части рекомендательный характер.
Заключение: После внесения незначительных правок рецензируемая статья может быть опубликована в журнале «Программные системы и вычислительные методы».

Полный текст рецензии на сайте
Национального Института Научного Рецензирования

QR код для проверки
подлинности рецензии

Результаты процедуры повторного рецензирования статьи

Рецензия выполнена специалистами Национального Института Научного Рецензирования по заказу ООО "НБ-Медиа".
В связи с политикой двойного слепого рецензирования личность рецензента не раскрывается.
Со списком рецензентов можно ознакомиться здесь.

Рецензируемая статья посвящена проблеме методической оценки производительности микросервисного взаимодействия в веб-фреймворках.
Оценка производительности требует комплексного подхода, включающего анализ пропускной способности, задержек, использования ресурсов и распределённой нагрузки. Среди широко распространенных методов оценки можно назвать нагрузочное тестирование, тестирование взаимодействия и мониторинг латентности. В рецензируемой статье авторами сделан акцент на использование первых двух методов из перечисленных.
1) Предмет и объект исследования
К сожалению, во вводной части, автором приводится достаточно четкие и понятные для читателя формулировки предмета и объекта исследования. Так, объектом исследования выступают серверные технологии, используемые при разработке микросервисных приложений, что находит развитие в аспекте предмета исследования - «экспериментальный анализ производительности микросервисного взаимодействия» в данной статье. Однозначно определены цель и задачи исследования, что придает значимость статьи в постановке проблемы исследования и ее возможного решения.
2) Методология (методика) исследования
Предлагаемая методика основана на единой архитектурной модели. Логически обоснованным выглядит последовательность (этапы) реализации предлагаемой методики. Справедливо сделана ссылка на критические факторы достоверности результатов, каковыми в частности, являются «архитектурная идентичность» и «особенности реализации исследуемых веб-фреймворков»
3) Актуальность
Рецензируемая статья имеет актуальность. Результатом оценки производительности является выявление ошибок в микросервисной архитектуре и соответствующее формулирование рекомендаций по их устранению. Отметим, что в целом, это принципиально позволяет повышать масштабируемость программной системы в целом.
4) Научная новизна
Научная новизна проведенного исследования состоит в разработке унифицированной методики для сравнительного анализа производительности различных микросервисных веб-фреймворков с учётом метрик потребления вычислительных ресурсов. Заслуживает внимания сделанный автором акцент на сопоставимости результатов между различными языками в рамках микросервисной архитектуры.
5) Практическая ценность
В статье приведены в достаточно большом объеме материалы экспериментального исследования. На их основе автором были сформулированы выводы по оценке производительности веб-фреймворков на базе микросервисной архитектуры. Результаты экспериментального исследования могут быть использованы для анализа производительности и в отношении других оцениваемых веб-фреймворков, при различных сценариях нагрузочного тестирования.
6) Стиль, структура и содержание
Стиль изложения статьи  технический. Структура статьи характеризуется логикой изложения материала. Содержание статьи раскрывает решение задач, сформулированных автором во Введении.
7) Библиография
Библиография в общем отражает проблематику исследования и является достаточно современной (не устаревшей).
8) Выводы и интерес для читательской аудитории
Считаем, что данная статья может вызвать интерес у определенного круга читательской аудитории, интересующихся проблемами построения интегрируемых программных систем.
Заключение: Рецензируемая статья может быть опубликована в журнале «Программные системы и вычислительные методы».

Полный текст рецензии на сайте
Национального Института Научного Рецензирования

QR код для проверки
подлинности рецензии