Шина событий Vertx и масштабирование Hazelcast ⇐ JAVA
Шина событий Vertx и масштабирование Hazelcast
В своем проекте я использую Vertx 4.4.5. Я создал несколько сервисов и достиг 3 тыс. TPS с 11 микросервисами на 18-ядерной виртуальной машине, работающей на Dell R730 с ОС RHEL 9. Каждый цикл запроса включает несколько операций чтения и записи в базе данных, а также в Redis. Redis и база данных находятся на одном компьютере, но на разных виртуальных машинах.
Размер сообщения составлял около 1 КБ, когда TPS составлял 3 КБ. Принимая во внимание, что когда я увеличиваю размер сообщения до ок. 100 КБ, что следует считать средним размером рабочего сообщения. TPS упал до 600. Я проверил журналы и обнаружил, что потребитель шины событий получает сообщение с задержкой в несколько секунд. Я погуглил и обнаружил, что шина событий не предназначена для больших сообщений, поэтому я использовал общие данные для записи моего сообщения размером 100 КБ на асинхронную карту и использовал шину событий для отправки apiKey только для целей идентификации и выборки. Итак, в моем следующем сервисе я асинхронно получаю эти данные с помощью этого APIKey из общей карты данных.
Проблема в том, что от сервиса A (ApiGateWay) до B (BusinessService) записываю все 100кб в общие данные и по завершению записи данных в общие данные
map.put(.., ..).onCompelete(res->{ если (res.succeed()) { eventBus.request(.., .., ..); } }); Я вызвал шину событий, используя
eventBus.request(.., .., ..); для отправки данных в следующую службу, тогда как в другой службе потребитель получает это сообщение после той же задержки, которая была раньше, когда я использовал шину событий, а не общие данные. Я также установил буфер сообщений потребителя на 10 КБ.
eventBus.consumer(.., ..).setMaxBufferedMessages(10000); Я что-то упустил? Некоторые другие конфигурации:
WorkerInstances на A -> 100 WorkerPoolSize на A -> 100
WorkerInstances на B -> 100 WorkerPoolSize на B -> 100
Я также пытался масштабировать hazelcast при запуске служб A и B, используя
-Dhazelcast.socket.receive.buffer.size=10240 -Dhazelcast.socket.send.buffer.size=10240 Загрузить сведения о запуске
[*]Джметр [*]7000 тем [*]100 циклов [*]Ускорение 0,7 с. [*]Постоянная задержка 1000 мс
Заранее благодарим за помощь. Ура!
В своем проекте я использую Vertx 4.4.5. Я создал несколько сервисов и достиг 3 тыс. TPS с 11 микросервисами на 18-ядерной виртуальной машине, работающей на Dell R730 с ОС RHEL 9. Каждый цикл запроса включает несколько операций чтения и записи в базе данных, а также в Redis. Redis и база данных находятся на одном компьютере, но на разных виртуальных машинах.
Размер сообщения составлял около 1 КБ, когда TPS составлял 3 КБ. Принимая во внимание, что когда я увеличиваю размер сообщения до ок. 100 КБ, что следует считать средним размером рабочего сообщения. TPS упал до 600. Я проверил журналы и обнаружил, что потребитель шины событий получает сообщение с задержкой в несколько секунд. Я погуглил и обнаружил, что шина событий не предназначена для больших сообщений, поэтому я использовал общие данные для записи моего сообщения размером 100 КБ на асинхронную карту и использовал шину событий для отправки apiKey только для целей идентификации и выборки. Итак, в моем следующем сервисе я асинхронно получаю эти данные с помощью этого APIKey из общей карты данных.
Проблема в том, что от сервиса A (ApiGateWay) до B (BusinessService) записываю все 100кб в общие данные и по завершению записи данных в общие данные
map.put(.., ..).onCompelete(res->{ если (res.succeed()) { eventBus.request(.., .., ..); } }); Я вызвал шину событий, используя
eventBus.request(.., .., ..); для отправки данных в следующую службу, тогда как в другой службе потребитель получает это сообщение после той же задержки, которая была раньше, когда я использовал шину событий, а не общие данные. Я также установил буфер сообщений потребителя на 10 КБ.
eventBus.consumer(.., ..).setMaxBufferedMessages(10000); Я что-то упустил? Некоторые другие конфигурации:
WorkerInstances на A -> 100 WorkerPoolSize на A -> 100
WorkerInstances на B -> 100 WorkerPoolSize на B -> 100
Я также пытался масштабировать hazelcast при запуске служб A и B, используя
-Dhazelcast.socket.receive.buffer.size=10240 -Dhazelcast.socket.send.buffer.size=10240 Загрузить сведения о запуске
[*]Джметр [*]7000 тем [*]100 циклов [*]Ускорение 0,7 с. [*]Постоянная задержка 1000 мс
Заранее благодарим за помощь. Ура!
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение
-
-
Ограничить клиентам hazelcast подключение к кластеру/экземпляру hazelcast.
Anonymous » » в форуме JAVA - 0 Ответы
- 20 Просмотры
-
Последнее сообщение Anonymous
-