Apache.HC 0 up to 50-100 Mb / sec via 1Gb ethernet.

потом взять кафку и посмотреть на перформанс )))

Ну тогда с тебя генерация случайных чисел с такой скоростью )))

Apache.HC просто транспорт поверх сокетов, 50-100 Mb сек в реальных приложениях видел. Вся потеря времени исключительно преобразовании кодовых страниц (Unicode-UTF8/1251) и двойной-тройной буфферизации поверх NIO.

p.s.
это только в документации/рекламе про нативное выделение памяти написано, что оно дает возможность (десять раз ха), избежать множественного копирование из памяти-в-память при общении с системой ввода-вывода. На практике, все обстоит с точностью до наоборот. Скорость одиночного доступа к нативной памяти, ниже самого нижайшего плинтуса. Если не скопировать в нормальную heap-область, все вообще будет стоять колом. Т.ч. при NIO количество копирований память-память ни только не уменьшается, а наоборот становится до неприличия ненормальным.
(дебажил Apache.HC, правда сильно предыдущих версий, но не думаю, что там что-то поменялось)

p.p.s.
Если под пересылкой ты имеешь в виду round-trip, отсылку и ответ, то тогда, скорее всего max 800-1000 сообщений в сек. на ethernet ))) Где-то 200-300 на ethernet 10 Mb, 400-500 на ethernet 100 Mb, 800-1000 на 1G и 1000-1200 на 10 Gb. ))) Нужно быстрее - покупайте нормальное оборудование, а не ethernet )))

Больно у Вас как-то сложно. Сообщения. Толстые, тонкие.

IMHO (упрощенно)

1. Может быть поток сообщений в одну сторону: 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37....

Толстое оно, тонкое - глубоко пофиг. Каждое число конечное тонкое, но все вместе - так толсто, что просто обзавидуешься

2. Может быть обмен требующий полноценных round-trip'ов

- Get first number
- 2
- Get next number
- 3
- Get next number
- 5
etc...etc..

Тут опять таки, толстое/тонкое... 10 G ethenet, Jumbo frame... и толстое уже и не настолько толстое

Но latency все равно будет ниже плинтуса, дабы Ethernet и TCP/IP. Родовая травма, которая лечится только полным выпиливаением.

Ну и loopback в данном случае будет совсем не показатель. Т.к. сильно зависит от OS. Т.к. "правильный" loopback (если повезет с реализацией в конретной OS), "плохой" loopback (если не повезет) и реальный ethernet - ничего общего иметь между собой не будут.

IMHO & AFAIK

p.s. примерное масштабирование технологии Ethernet я показал выше. С каждым поколением:
Цифирька скорости увеличивается на один нолик
А латенси падает (кол-во round trip в секунду растет) только где-то в два раза
p.p.s. сферические тесты сети вроде под 50 000 сообщений в секунду на 1Gb Ethernet показывают. Но то сферические тесты на C. Как только что-то прикладное, то минимум нолик удаляй, а то и все два.

C рабитами, кафками не сталкивался

Т.к. там, где реально большие нагрузки (tradingview.com) все сообщения посылали руками через HTTP и проблем не знали

В текущей прикладной области enterprise: прикладных систем очень много, но организация одна. Т.ч. db-link и так же, проблем не знаем. Нафиг нам эти Ваши кафки?

Был опыт работы со СМЭВ и ГИС ГМП ))) Такой себе опыт. Электронный документооборот в виде сообщений с TIFF-сканами, которые потом распечатываются на бумагу на принтере, с клавиатуры вводятся в прикладную систему (ну или еще что-то с ними делается), из прикладной системы распечатывается отчет, сканируется, TIFF-файл посылается через СМЭВ, всякие кафки и SOAP'ы. Полностью ассинхронный, импортозамещенный, электронный документооборот.
(опыт многолет назад, сейчас, возможно, все не так комично)

ГИС ГМП тот момент более-менее заставили использовать ГАИ, но в налогой инспекции внедрение застопорилось