Да, базовый образ контейнеров был на Ubuntu. В целом, думаю, что можно и с Jetty тесты прогнать. Не уверен, что получится оперативно это сделать, но, как сделаю, отпишусь в комменте.
Исходный код, к сожалению, закрыт, так как микросервисы разработаны в рамках платного курса. А трассировка уже есть, поэтому не могу сказать, какие результаты были бы без нее.
Сделал прогон POST /v1/menu-orders на Spring MVC без Virtual Threads. В качестве ClientHttpRequestFactory была HttpComponentsClientHttpRequestFactory с параметрами maxConnectionsPerRoute = 200 и maxConnectionsTotal = 200.
Показатели по временам сравнимы с VT и чуть похуже, чем WebFlux p95=49ms p99=141ms
По CPU заметно лучше чем VT или WebFlux 64% CPU.
По памяти также чуть лучше VT или WebFlux 267 MiB heap.
А вот прогон GET /v1/menu-aggregate не удался - примерно на 1700rps GC перестает справляться, heap уходит в полку и приклад перестает отвечать. Пробовал несколько раз, симптомы повторяются. Снижать нагрузку еще больше не стал. В качестве ClientHttpRequestFactory была HttpComponentsClientHttpRequestFactory с параметрами maxConnectionsPerRoute = 200 и maxConnectionsTotal = 200. Попробовал также снизить количество коннектов maxConnectionsPerRoute = 100 и maxConnectionsTotal = 100 - картина та же. Сегодня разбираться уже нет времени, но надо подумать, с чем это связано.
Бесспорно, сложность разработки и поддержки WebFlux гораздо выше WebMVC, и WebFlux выбирают осознанно. Также я не раз слышал утверждения о том, что WebFlux будет лучше по перформансу, чем виртуальные потоки. Но я придерживаюсь позиции, что лучше проверить, чем просто поверить, тем более, есть над чем ставить эксперименты. И также хотелось понять на сколько VT проиграют WebFlux и в чем, чтобы понимать, есть ли смысл менять сложную парадигму программирования на более привычную с учетом некоторого проигрыша по latency. Ну, и также важно учесть, что WebFlux в некоторых случаях при одинаковой нагрузке потребляет гораздо больше CPU, то есть потребуется горизонтальное масштабирование, а это дополнительные деньги. В общем, как всегда - поиск компромисса, но в этом поиске хочется основываться на цифрах, а не на слухах и ощущениях)
Хм... Звучит интересно. Надо подумать. В нашем проекте, естественно, не такая примитивная логика - она сопряжена с возможностью сохранения черновиков товаров, валидацией информации, взаимодействием со сторонними ресурсами, поэтому пока не могу однозначно сказать, что будет ли достаточно хранения в Postgres только команд, а не сущностей.
Если я правильно понял вашу мысль, то в этом случае всю логику обновления/удаления придется выносить на уровень приложения. Это рабочий вариант, но он увеличит время транзакции, также вырастет объем данных, передаваемых по сети между базой и приложением.
Соглашусь, удовольствие - так себе. Но надо признать, что в целом работа с json возможна и достаточно эффективна по сравнению с большим количеством join-ов (это отсылка к статье "Замена EAV на JSONB в PostgreSQL").
Да, действительно так и есть. Я этот момент не учел. Спасибо за замечание! Однако Debezium 2.4.0.FINAL пока еще может работать только с primary серверами Postgres. PostgreSQL 16 introduces logical replication from standby servers; however, this feature has not yet been tested by Debezium and will be a feature introduced in a later build of Debezium. For now, logical replication remains only supported via the primary. https://debezium.io/blog/2023/10/03/debezium-2-4-final-released/ Debezium версии 2.5 (еще в development) это исправит https://issues.redhat.com/browse/DBZ-7181
Спасибо за замечание! Да, действительно с таким подходом будет более стабильная архитектура. Тут можно было бы использовать, например, Postgres в качестве основной базы для заказов и Debezium в качестве source / sink Kafka connector. В статье же я придерживался того подхода, который предлагают в Confluent, где они используют саму Kafka в качестве single source of truth.
Да, базовый образ контейнеров был на Ubuntu. В целом, думаю, что можно и с Jetty тесты прогнать. Не уверен, что получится оперативно это сделать, но, как сделаю, отпишусь в комменте.
Исходный код, к сожалению, закрыт, так как микросервисы разработаны в рамках платного курса. А трассировка уже есть, поэтому не могу сказать, какие результаты были бы без нее.
Сделал прогон POST /v1/menu-orders на Spring MVC без Virtual Threads. В качестве ClientHttpRequestFactory была HttpComponentsClientHttpRequestFactory с параметрами maxConnectionsPerRoute = 200 и maxConnectionsTotal = 200.
Показатели по временам сравнимы с VT и чуть похуже, чем WebFlux p95=49ms p99=141ms
По CPU заметно лучше чем VT или WebFlux 64% CPU.
По памяти также чуть лучше VT или WebFlux 267 MiB heap.
А вот прогон GET /v1/menu-aggregate не удался - примерно на 1700rps GC перестает справляться, heap уходит в полку и приклад перестает отвечать. Пробовал несколько раз, симптомы повторяются. Снижать нагрузку еще больше не стал. В качестве ClientHttpRequestFactory была HttpComponentsClientHttpRequestFactory с параметрами maxConnectionsPerRoute = 200 и maxConnectionsTotal = 200. Попробовал также снизить количество коннектов maxConnectionsPerRoute = 100 и maxConnectionsTotal = 100 - картина та же. Сегодня разбираться уже нет времени, но надо подумать, с чем это связано.
Бесспорно, сложность разработки и поддержки WebFlux гораздо выше WebMVC, и WebFlux выбирают осознанно. Также я не раз слышал утверждения о том, что WebFlux будет лучше по перформансу, чем виртуальные потоки. Но я придерживаюсь позиции, что лучше проверить, чем просто поверить, тем более, есть над чем ставить эксперименты. И также хотелось понять на сколько VT проиграют WebFlux и в чем, чтобы понимать, есть ли смысл менять сложную парадигму программирования на более привычную с учетом некоторого проигрыша по latency. Ну, и также важно учесть, что WebFlux в некоторых случаях при одинаковой нагрузке потребляет гораздо больше CPU, то есть потребуется горизонтальное масштабирование, а это дополнительные деньги. В общем, как всегда - поиск компромисса, но в этом поиске хочется основываться на цифрах, а не на слухах и ощущениях)
Я не сравнивал конфигурацию на Tomcat + VT и Tomcat на обычных потоках. Могу сделать пару прогонов, если интересно.
Хм... Звучит интересно. Надо подумать. В нашем проекте, естественно, не такая примитивная логика - она сопряжена с возможностью сохранения черновиков товаров, валидацией информации, взаимодействием со сторонними ресурсами, поэтому пока не могу однозначно сказать, что будет ли достаточно хранения в Postgres только команд, а не сущностей.
Если я правильно понял вашу мысль, то в этом случае всю логику обновления/удаления придется выносить на уровень приложения. Это рабочий вариант, но он увеличит время транзакции, также вырастет объем данных, передаваемых по сети между базой и приложением.
Соглашусь, удовольствие - так себе. Но надо признать, что в целом работа с json возможна и достаточно эффективна по сравнению с большим количеством join-ов (это отсылка к статье "Замена EAV на JSONB в PostgreSQL").
Да, действительно так и есть. Я этот момент не учел. Спасибо за замечание! Однако Debezium 2.4.0.FINAL пока еще может работать только с primary серверами Postgres. PostgreSQL 16 introduces logical replication from standby servers; however, this feature has not yet been tested by Debezium and will be a feature introduced in a later build of Debezium. For now, logical replication remains only supported via the primary. https://debezium.io/blog/2023/10/03/debezium-2-4-final-released/ Debezium версии 2.5 (еще в development) это исправит https://issues.redhat.com/browse/DBZ-7181
Спасибо за замечание! Да, действительно с таким подходом будет более стабильная архитектура. Тут можно было бы использовать, например, Postgres в качестве основной базы для заказов и Debezium в качестве source / sink Kafka connector. В статье же я придерживался того подхода, который предлагают в Confluent, где они используют саму Kafka в качестве single source of truth.
Спасибо за совет! Добавил)