Move compute-heavy endpoints off event loop on to worker threads#2310
Open
Move compute-heavy endpoints off event loop on to worker threads#2310
Conversation
| mainRouter.post(V2_IDENTITY_BUCKETS.toString()).handler(bodyHandler).handler(auth.handleV1( | ||
| rc -> encryptedPayloadHandler.handle(rc, this::handleBucketsV2), Role.MAPPER)); | ||
| rc -> encryptedPayloadHandler.handleAsync(rc, this::handleBucketsV2Async), Role.MAPPER)); | ||
| mainRouter.post(V2_IDENTITY_MAP.toString()).handler(bodyHandler).handler(auth.handleV1( |
Contributor
There was a problem hiding this comment.
You don't have to do all this.. please just swap the existing handler with blockingHandler, ordered = false: https://vertx.io/docs/apidocs/io/vertx/ext/web/Route.html#blockingHandler(io.vertx.core.Handler,boolean)
Contributor
Author
There was a problem hiding this comment.
Why I didn’t use blockingHandler
- It runs on Vert.x’s default worker pool, and it cannot be configured to run on a different pool
- The default worker pool also handles store sync operations (e.g., RotatingStoreVerticle and CloudSyncVerticle from uid2 shared), some of which are IO bound
- Without a way to isolate these tasks, IO bound tasks might block the worker threads, slowing down processing of batch requests
- This interference would also distort queue metrics (both wait time and queue length), as the queue would reflect not only request load but also other background tasks. That would make alerts (and potential HPA scaling based on them) flakier
…ol' of github.com:IABTechLab/uid2-operator into srm-UID2-6480-move-compute-heavy-endpoints-to-worker-pool
…ol' of github.com:IABTechLab/uid2-operator into srm-UID2-6480-move-compute-heavy-endpoints-to-worker-pool
cYKatherine
reviewed
Feb 3, 2026
|
|
||
| // Create shared compute pool for CPU-intensive operations | ||
| final int computePoolSize = config.getInteger(Const.Config.ComputePoolThreadCountProp, Math.max(1, Runtime.getRuntime().availableProcessors() - 2)); | ||
| final WorkerExecutor computeWorkerPool = vertx.createSharedWorkerExecutor("compute", computePoolSize); |
Contributor
There was a problem hiding this comment.
nit: Maybe rename the compute worker pool with a meaningful name (eg: "cpu intensive compute")
cYKatherine
reviewed
Feb 3, 2026
| // Create shared compute pool for CPU-intensive operations | ||
| final int computePoolSize = config.getInteger(Const.Config.ComputePoolThreadCountProp, Math.max(1, Runtime.getRuntime().availableProcessors() - 2)); | ||
| final WorkerExecutor computeWorkerPool = vertx.createSharedWorkerExecutor("compute", computePoolSize); | ||
| LOGGER.info("Created compute worker pool with size: {}", computePoolSize); |
Contributor
There was a problem hiding this comment.
nit: maybe log the name of the worker pool as we might add more worker pools in the future for different usage
cYKatherine
reviewed
Feb 3, 2026
|
|
||
| Supplier<Verticle> operatorVerticleSupplier = () -> { | ||
| UIDOperatorVerticle verticle = new UIDOperatorVerticle(configStore, config, this.clientSideTokenGenerate, siteProvider, clientKeyProvider, clientSideKeypairProvider, getKeyManager(), saltProvider, optOutStore, Clock.systemUTC(), _statsCollectorQueue, new SecureLinkValidatorService(this.serviceLinkProvider, this.serviceProvider), this.shutdownHandler::handleSaltRetrievalResponse, this.uidInstanceIdProvider); | ||
| UIDOperatorVerticle verticle = new UIDOperatorVerticle(configStore, config, this.clientSideTokenGenerate, siteProvider, clientKeyProvider, clientSideKeypairProvider, getKeyManager(), saltProvider, optOutStore, Clock.systemUTC(), _statsCollectorQueue, new SecureLinkValidatorService(this.serviceLinkProvider, this.serviceProvider), this.shutdownHandler::handleSaltRetrievalResponse, this.uidInstanceIdProvider, computeWorkerPool); |
Contributor
There was a problem hiding this comment.
Question (maybe also for @sunnywu @mcollins-ttd @vishalegbert-ttd ), do we prefer using dependency injection for the WorkerExecutor here, or should we simply pass the pool name?
Since vertx.createSharedWorkerExecutor("name") acts as a "get or create," we can easily fetch the shared pool internally without passing the object.
- Pros for DI: It makes mocking easier for unit tests.
- Cons: It might become annoying if we introduce multiple distinct pools in the future (e.g., separating the 'identity map' pool from other heavy compute endpoints), as we'd have to update constructor signatures for every new pool.
wdyt?
…ol' of github.com:IABTechLab/uid2-operator into srm-UID2-6480-move-compute-heavy-endpoints-to-worker-pool
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes made:
Tests ran: