1. Обзор
В этой статье мы проведем простое сравнение между двумя известными платформами Java, Spring Boot и Quarkus. В конце мы лучше поймем различия и сходства между ними, а также некоторые особенности.
Кроме того, мы проведем несколько тестов, чтобы измерить их производительность и понаблюдать за их поведением.
2. Весенний ботинок
Spring Boot — это фреймворк на основе Java, ориентированный на корпоративные приложения . Он объединяет все проекты Spring и помогает повысить производительность разработчиков, предлагая множество готовых интеграций .
Делая это, он уменьшает количество конфигураций и шаблонов. Кроме того, благодаря своему подходу к настройке , который автоматически регистрирует конфигурации по умолчанию на основе зависимостей, доступных в пути к классам во время выполнения, Spring Boot значительно сокращает время выхода на рынок для многих приложений Java.
3. Кваркус
Quarkus — это еще один фреймворк с подходом, аналогичным упомянутому выше Spring Boot, но с дополнительным обещанием предоставлять меньшие артефакты с быстрой загрузкой, лучшим использованием ресурсов и эффективностью .
Он оптимизирован для облачных, бессерверных и контейнерных сред. Но, несмотря на эту немного другую направленность, Quarkus также хорошо интегрируется с наиболее популярными платформами Java.
4. Сравнение
Как упоминалось выше, оба фреймворка отлично интегрируются с другими проектами и фреймворками. Однако их внутренние реализации и архитектуры различны. Например, Spring Boot предлагает веб-возможности двух видов: блокирующие (сервлеты) и неблокирующие (WebFlux) .
С другой стороны, Quarkus также предлагает оба подхода, но в отличие от Spring Boot позволяет нам одновременно использовать и блокирующий, и неблокирующий подходы . Более того, Quarkus имеет реактивный подход, встроенный в его архитектуру .
По этой причине, чтобы иметь более точный сценарий в нашем сравнении, мы будем использовать два полностью реактивных приложения, реализованных с реактивными возможностями Spring WebFlux и Quarkus .
Кроме того, одной из наиболее важных функций, доступных в проекте Quarkus, является возможность создавать собственные образы (двоичные и специфичные для платформы исполняемые файлы). Итак, мы также включим в сравнение оба нативных образа, но в случае Spring поддержка нативных образов пока находится на экспериментальной стадии . Для этого нам понадобится GraalVM .
4.1. Тестовые приложения
Наше приложение будет предоставлять три API: один позволяет пользователю создавать почтовый индекс, другой — находить информацию о конкретном почтовом индексе и, наконец, запрашивать почтовые индексы по городам. Эти API были реализованы с использованием как Spring Boot, так и Quarkus, полностью с использованием реактивного подхода, как уже упоминалось, и с использованием базы данных PostgreSQL.
Цель состояла в том, чтобы создать простой образец приложения, но немного более сложный, чем приложение HelloWorld. Конечно, это повлияет на наше сравнение, поскольку реализация таких вещей, как драйверы баз данных и среды сериализации, повлияет на результат. Тем не менее, большинство приложений, вероятно, имеют дело и с этими вещами.
Таким образом, наше сравнение не направлено на то, чтобы быть истиной в последней инстанции о том, какой фреймворк лучше или более производительный, а скорее на конкретном примере, в котором будут проанализированы эти конкретные реализации.
4.2. Планирование тестирования
Чтобы протестировать обе реализации, мы будем использовать JMeter для выполнения теста и отчета о его показателях для анализа наших результатов. Кроме того, мы будем использовать VisualVM для мониторинга использования ресурсов приложений во время выполнения теста.
Тест будет выполняться в течение 5 минут, при этом будут вызываться все API, начиная с периода прогрева и после увеличения числа одновременных пользователей до достижения 1500 из них. Мы начнем заполнять базу данных в течение первых секунд, а затем начнутся запросы, как показано ниже:
Все испытания проводились на машине со следующими характеристиками:
Хотя это и не идеально из-за отсутствия изоляции от других фоновых процессов, тест предназначен только для иллюстрации предлагаемого сравнения. Мы не собираемся предоставлять обширный и подробный анализ производительности обоих фреймворков, как уже упоминалось.
5. Выводы
Опыт разработчиков был отличным для обоих проектов, но стоит отметить, что Spring Boot имеет лучшую документацию и больше материалов, которые мы можем найти в Интернете. Quarkus совершенствуется в этой области, но все еще немного отстает.
По показателям имеем:
С помощью этого эксперимента мы могли наблюдать, что Quarkus был почти в два раза быстрее Spring Boot с точки зрения времени запуска как в JVM, так и в нативной версии . Время сборки также было намного быстрее. В случае нативных образов сборка заняла 121 секунду (Quarkus) против 176 секунд (Spring Boot), а сборка JVM заняла 7,9 секунды (Quarkus) против 22,44 секунды (Spring Boot).
Что касается размера артефакта, то исполняемые артефакты, созданные Spring Boot и Quarkus, были одинакового размера.
Однако в отношении других показателей выводы не однозначны. Итак, давайте более подробно рассмотрим некоторые из них.
5.1. Процессор
Если мы сосредоточимся на использовании ЦП, мы увидим, что версии JVM потребляют больше ЦП в начале на этапе прогрева. После этого загрузка ЦП стабилизируется , и потребление становится относительно одинаковым для всех версий.
Вот потребление ЦП для Quarkus в версиях JVM и Native в указанном порядке:
5.2. Память
С памятью все еще сложнее. Во-первых, очевидно, что JVM-версии обоих фреймворков резервируют больше памяти для кучи . Тем не менее верно и то, что Quarkus резервирует меньше памяти с самого начала, и то же самое верно и для использования памяти во время запуска.
Затем, глядя на использование во время теста, мы можем заметить, что нативные образы, похоже, не так эффективно и часто собирают память, как версии JVM . Это можно улучшить, изменив некоторые параметры. Тем не менее, в этом сравнении мы использовали только параметры по умолчанию.
Поэтому никаких изменений в GC, опции JVM или любые другие параметры не вносилось.
Посмотрим на графики использования памяти:
(JVM с весенней загрузкой)
(Кваркус JVM)
(Родной Spring Boot)
(Родной Quarkus)
Похоже, что Quarkus потреблял меньше ресурсов памяти, несмотря на более высокие всплески во время теста.
5.3. Время отклика
Наконец, что касается времени отклика и количества потоков, используемых в пике, Spring Boot здесь, похоже, имеет преимущество . Он смог справиться с той же нагрузкой, используя меньшее количество потоков, а также с лучшим временем отклика.
В этом случае версия Spring Boot Native показала лучшую производительность. Но давайте посмотрим на распределение времени отклика каждой версии приложения:
(JVM с весенней загрузкой)
Несмотря на большее количество выбросов, версия Spring Boot JVM со временем претерпела наилучшие изменения, скорее всего, из-за оптимизации JIT-компилятора :
(Кваркус JVM)
(Родной Spring Boot)
(Родной Quarkus)
Quarkus показал себя мощным с точки зрения низкого использования ресурсов. Однако, по крайней мере, в этом эксперименте Spring Boot показал лучшую пропускную способность и отзывчивость. Несмотря на это, оба фреймворка смогли обработать все запросы без каких-либо ошибок.
Не только это, но и их производительность была довольно похожей, и между ними не было существенного различия.
5.4. Соединение точек
Учитывая все обстоятельства, обе платформы оказались отличными вариантами, когда дело дошло до реализации Java-приложений.
Нативные приложения продемонстрировали свою скорость и низкое потребление ресурсов, являясь отличным выбором для бессерверных недолговечных приложений и сред, где критически важно низкое потребление ресурсов.
С другой стороны, приложения JVM, по-видимому, имеют больше накладных расходов, но обладают превосходной стабильностью и высокой пропускной способностью с течением времени, что идеально подходит для надежных и долгоживущих приложений.
6. Заключение
В этой статье мы сравнили фреймворки Spring Boot и Quarkus и их различные режимы развертывания, JVM и Native. Мы также рассмотрели другие показатели и аспекты этих приложений.
Как обычно, код тестового приложения и скрипты, используемые для их тестирования, доступны на GitHub .