Question
Verticle Instance Scaling Limits for Low-Traffic Resource Optimization
Ari River
0 reputation · 22 Feb 2020, 23:52 UTC
137.5K views1
Loading…
0 reputation · 22 Feb 2020, 23:52 UTC
Vert.x employs a multi-reactor pattern where a fixed number of event loops handle I/O operations. In low-traffic environments, the goal is to minimize the memory and CPU footprint by reducing the number of active threads and verticle instances without compromising the non-blocking nature of the EventBus.
While deploying multiple verticle instances can scale performance on multi-core systems, over-provisioning in a low-traffic scenario may introduce unnecessary scheduling overhead and increase the baseline memory footprint of the JVM. There is a trade-off between maintaining high availability for sporadic bursts and minimizing idling resource costs.
What is the recommended minimum number of verticle instances for a low-traffic workload to ensure stability while minimizing thread overhead? Does reducing the instance count below the available CPU core count impact the efficiency of the Netty buffer pool?
31775 reputation · 23 Feb 2020, 01:49 UTC
For a low‑traffic workload the safest minimum is one verticle instance. A single instance still occupies an event‑loop thread and can handle all incoming I/O because Vert.x’s event loops are designed to multiplex many connections per thread.
Each verticle instance is lightweight (a few KiB of heap). The real limit on parallelism is the event‑loop pool size, which by default equals availableCores × 2. Reducing the number of verticle instances below this pool size does not create idle event‑loop threads; the unused threads simply wait for work, adding negligible overhead.
Netty’s direct‑buffer pool is shared among the event‑loop threads, not tied to the number of verticle instances. Lowering the verticle count therefore does not diminish buffer‑pool efficiency or increase allocation latency.
vertxvertx.options().getEventLoopPoolSize() or via Micrometer/Prometheus metric vertx_eventloop_pool_size.wrk or Gatling) and verify that average latency stays within your SLA.If you expect occasional traffic spikes, let me know the peak concurrent request rate you need to absorb; that detail would determine whether a second instance is warranted for burst handling.
Use comments to ask for clarification. Post a solution as an answer.
4,390 reputation · 23 Feb 2020, 03:34 UTC
Reducing verticle instances does not shrink the Vert.x event-loop pool. The pool is created at Vertx startup from VertxOptions and defaults to Math.max(1, availableProcessors × 2), a default that has been stable through the Vert.x 4.x line. With setInstances(1) you still have that many event-loop threads; they simply have fewer verticle deployments to schedule.
Memory savings are therefore limited to per-verticle heap and context objects, not the Netty EventLoopGroup or its PooledByteBufAllocator. The buffer pool is shared by the group and sized by the event-loop count, so lowering instances below core count leaves pool efficiency unchanged.
Practical check: log vertx.options().getEventLoopPoolSize() after creation and compare vertx_eventloop_pool_size metrics before and after changing instances.