Synchronous crypto.pbkdf2Sync vs. asynchronous crypto.pbkdf2 for handling concurrent requests in Node.js

Goal: Identify whether using the synchronous crypto.pbkdf2Sync function or its asynchronous counterpart crypto.pbkdf2 yields lower latency spikes when the server handles many concurrent requests.

Constraint: The synchronous call blocks the Node.js event loop, causing all incoming requests to wait until the operation finishes, while the asynchronous call offloads work to the libuv threadpool, which is limited by UV_THREADPOOL_SIZE and can queue tasks under high concurrency.

Uncertainty: It is not evident which trade‑off—event‑loop blocking versus threadpool queuing—produces better 99th‑percentile latency for realistic payload sizes and iteration counts, especially when the number of concurrent connections exceeds the default threadpool size.

Which approach results in lower average latency under a sustained load of 200 concurrent requests?

Does increasing UV_THREADPOOL_SIZE mitigate the latency disadvantage of the asynchronous variant, or does it merely shift the bottleneck elsewhere?