EventBus send latency rises under concurrent load

When measuring the Vert.x EventBus vertx.eventbus.send.timer metric while increasing the number of concurrent sender verticles, the observed latency shows a noticeable increase.

The goal is to determine whether this rise stems from contention on the shared EventBus event‑loop thread, from the overhead of the metrics instrumentation, or from a combination of both.

Constraints include preserving any ordering guarantees required by the application and avoiding the introduction of blocking work that would skew the measurements.

Is the latency increase primarily caused by competition for the single event‑loop thread that processes all messages on the default shared EventBus? Would creating multiple local EventBus instances per verticle or worker pool alleviate the contention without violating required ordering semantics? How can the impact of the metrics SPI be isolated so that the baseline EventBus processing time can be measured accurately?