Vert.x HTTP Server and Worker Verticle: Does Offloading Blocking JDBC to a Worker Verticle Eliminate Concurrency‑Dependent Latency Spikes?

The goal is to determine whether moving blocking JDBC operations from an event‑loop verticle to a dedicated worker verticle removes the latency spikes that appear only under high concurrent request loads in a Vert.x‑based HTTP server.

Constraints include the default shared worker pool size (available processors × 2), which may become a bottleneck when the number of concurrent blocking tasks exceeds it; the exact threshold depends on the Vert.x version and the number of CPU cores. Additionally, visibility into event‑loop blocked time and worker‑pool queue depth requires Vert.x metrics to be enabled (e.g., via Micrometer or Dropwizard); without these metrics it is difficult to isolate whether latency originates from event‑loop stalls or worker‑pool queuing.

What worker pool size is needed to avoid queuing of blocking JDBC tasks at a given concurrency level, and how does this size interact with the default event‑loop thread count?

When Vert.x metrics are enabled, how can one correlate observed latency spikes with increases in the ‘event.loop.blocked.time’ gauge versus the ‘worker.pool.queue.size’ gauge to confirm the source of the delay?