Статьи

Сравнение синхронного и асинхронного доступа к Postgres

Quarkus поддерживает императивные и реактивные стили программирования. В этой статье я сравниваю время доступа к Postgres из микросервисов на основе Java, разработанных с помощью Quarkus. Для синхронных вызовов используется Panache, для асинхронного доступа — Vert.x Axle.

Я создал пример приложения, которое поставляется с проектом cloud-native-starter . Микросервис «article» обращается к базе данных, работающей в Kubernetes. Для простоты сценария тестируется только один REST API, который читает статьи из Postgres.

Сервис статей доступен в двух вариантах:

  1. Обязательный / синхронный: конечная точка REST была реализована с помощью JAX-RS (синхронно). Сервис читает статьи из Postgres через Panache (см. Руководство Quarkus по упрощенному Hibernate ORM с Panache ).
  2. Реактивный / асинхронный: конечная точка REST была реализована с помощью асинхронно Vert.x, CompletionStage и CompletableFuture. Служба асинхронно читает статьи из Postgres через Vert.x Axle (см. Руководство Quarkus « Реактивные клиенты SQL» ).

Реактивный стек этого образца обеспечивает время отклика, которое занимает менее половины времени по сравнению с императивным стеком : Реактивный: 142 мс (всего 0:42 мин) — Императивный: 265 мс (всего 1:20 мин). Проверьте документацию для деталей.

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

Я провел второй тест производительности, где тестируется более полное облачное приложение. Ознакомьтесь с документацией .

Синхронный доступ через Panache

Panache — это расширение JPA, которое делает упорство действительно простым. После того, как вы определили зависимости и конфигурацию в application.properties , вы можете определить сущность (см. Код ):


Джава