crypto: add WebCrypto sync job fast paths#63595
Conversation
Signed-off-by: Filip Skokan <panva.ip@gmail.com>
|
Code is ok. I'm somewhat concerned by this change, and I think it needs to be validated a bit more. I don't know if there is a best choice for this. If the resources are constrained, sync is inherently better (as it prevents the queue from growing), but I can see I might want to tune this behavior to my application. |
I checked. Results are not good as you suspected. Factoring in http-server responsiveness severly limits what we could mark as a sync candidate, what remains is non-rsa keygen and symmetric ops (hmac, encrypt/decrypt) but with threshold below 4kB, sometimes 8kB, rather than 64kB. So it's sort of pointless to continue with this spike, too big of a churn and maintenance burden over too small an impact. |
2 participants
Note
This is a work in progress, i just need a PR to use benchmark-node-micro-benchmarks
TL;DR A WebCrypto sync operation candidate runs synchronously only when it passes its operation-specific limits and no other candidate has used the sync slot since the last microtask checkpoint; otherwise, fanout before the next checkpoint or the async pressure window sends it to the threadpool.
Benchmark
This adds a WebCrypto-specific synchronous CryptoJob fast path for selected low-cost operations while preserving Promise-based WebCrypto semantics.
The existing WebCrypto implementation always dispatched these jobs to the libuv threadpool. For small inputs and low-cost key operations, the threadpool orchestration cost can dominate the native crypto work. This change adds
kCryptoJobSyncWebCrypto, which performs the native work on the current thread while still resolving or rejecting the returned Promise using WebCrypto result and error semantics.The JavaScript WebCrypto layer now chooses between async and sync WebCrypto job modes before constructing the native job. The selection is limited to explicit sync candidates and is guarded by operation-specific thresholds, RSA modulus limits, and a small per-turn sync budget. This lets sequential
awaitusage take the fast path while same-turn fanout falls back to async jobs for parallel throughput.Sync candidates include selected small-input digest, cipher, MAC, HKDF, RSA verify, ECDSA, and EdDSA operations, selected ECDH operations, ML-KEM encapsulation/decapsulation, and WebCrypto symmetric and non-RSA asymmetric key generation. No WebCrypto operation is unconditionally sync; the sync path is always a candidate path and can still fall back to async mode.