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

Question

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?

Tasadduq Burney · Answer

Direct answerMoving blocking JDBC calls from an event‑loop verticle to a dedicated worker verticle removes latency spikes that are caused by event‑loop stalls, but it does **not** guarantee the elimination of all concurrency‑dependent latency spikes. If the worker pool becomes saturated, tasks will queue there and produce similar spikes.Confirmed factsVert.x creates eventLoopPoolSize = availableProcessors event‑loop threads and a default worker pool of workerPoolSize = availableProcessors × 2 (Vert.x 4.x).When a blocking operation runs on an event‑loop thread, the thread is blocked and the gauge event.loop.blocked.time rises, directly correlating with latency spikes.Offloading the JDBC call to a worker verticle keeps the event‑loop free, so event.loop.blocked.time stays low.If the number of concurrent blocking JDBC calls exceeds the worker pool size, the gauge worker.pool.queue.size grows and latency spikes reappear, now reflecting worker‑pool queuing.Steps to verify and size the worker poolEnable Vert.x metrics (Micrometer or Dropwizard) and expose the gauges event.loop.blocked.time and worker.pool.queue.size.Run a controlled load test (e.g., wrk, Gatling) with a known concurrent request rate while recording latency percentiles.Before offloading, confirm that latency spikes align with rises in event.loop.blocked.time and that worker.pool.queue.size remains near zero.After moving JDBC to a worker verticle, observe whether latency spikes disappear and worker.pool.queue.size stays low.If spikes persist and correlate with growth in worker.pool.queue.size, increase the worker pool size via VertxOptions.setWorkerPoolSize(int) and repeat the test.Continue adjusting until worker.pool.queue.size stays low under the target concurrency; the required size is at least the peak concurrent blocking JDBC requests.Missing diagnostic detailTo decide whether to increase the worker pool, we need the observed value of worker.pool.queue.size during the latency spikes. If this gauge is near zero, the spikes are likely due to another source; if it is high, sizing the pool upward is the appropriate next step.

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

1 answer

Direct answer

Confirmed facts

Steps to verify and size the worker pool

Missing diagnostic detail

Your perspective belongs here.

0 question comments