Description
Loading a large number of secrets from Azure Key Vault via AzureKeyVault.mapSecrets/mapKeyProperties is very slow when Web3Signer runs in a container with tight CPU limits — to the point of being impractical for vaults with tens of thousands of secrets.
Environment
Container resources:
resources:
limits:
cpu: "1"
memory: 2Gi
requests:
cpu: 500m
memory: 1GiVault contains 20001 secrets.
Observed
2026-08-06 15:28:52.619+0000 | ForkJoinPool.commonPool-worker-1 | INFO | BLS | BLS: loaded BLST library
2026-08-06 15:37:17.166+0000 | artifact-signer-loader | INFO | Eth2Runner | Keys loaded from Azure: [20001], with error count: [0]
2026-08-06 15:37:19.104+0000 | artifact-signer-loader | INFO | RegisteredValidators | Validators registered successfully in database:20001
~8 minutes 30 seconds to load 20001 keys.
Root cause
AzureKeyVault.mapSecrets/mapKeyProperties list secrets in pages of 25 (PagedIterable.streamByPage()) and only parallelize the per-secret getSecret calls within a page, via parallelStream() on the common ForkJoinPool. Two things compound under constrained resources:
- The next page isn't listed until every secret in the current page has been fetched — no overlap between listing and fetching.
parallelStream() sizes its parallelism off Runtime.availableProcessors(), which under cpu: "1" reports very few available processors — so the "parallel" fetch barely parallelizes, and network round-trip latency to Azure Key Vault dominates.
Net effect: with ~20k secrets, load time scales close to linearly with per-secret request latency.
Proposal
Fetch secrets/keys concurrently with an explicit, configurable concurrency bound (decoupled from the container's CPU limit), while continuing to list subsequent pages in the background instead of waiting for the current page's fetches to complete.
Description
Loading a large number of secrets from Azure Key Vault via
AzureKeyVault.mapSecrets/mapKeyPropertiesis very slow when Web3Signer runs in a container with tight CPU limits — to the point of being impractical for vaults with tens of thousands of secrets.Environment
Container resources:
Vault contains 20001 secrets.
Observed
~8 minutes 30 seconds to load 20001 keys.
Root cause
AzureKeyVault.mapSecrets/mapKeyPropertieslist secrets in pages of 25 (PagedIterable.streamByPage()) and only parallelize the per-secretgetSecretcalls within a page, viaparallelStream()on the commonForkJoinPool. Two things compound under constrained resources:parallelStream()sizes its parallelism offRuntime.availableProcessors(), which undercpu: "1"reports very few available processors — so the "parallel" fetch barely parallelizes, and network round-trip latency to Azure Key Vault dominates.Net effect: with ~20k secrets, load time scales close to linearly with per-secret request latency.
Proposal
Fetch secrets/keys concurrently with an explicit, configurable concurrency bound (decoupled from the container's CPU limit), while continuing to list subsequent pages in the background instead of waiting for the current page's fetches to complete.