crypto.sign doesn't use libuv worker/thread pool but instead blocks event loop

[brandonros]

Version: 10.15.3 LTS
System/subsystem: Linux

I'm not sure if this is by intention or design but it seems like the internal crypto library does not provide a way to sign payloads without blocking the event loop.

const signJwt = (privateKey, header, payload) => {
  const securedInput = `${Buffer.from(JSON.stringify(header)).toString('base64')}.${Buffer.from(JSON.stringify(payload)).toString('base64')}`
  const signature = crypto.createSign('RSA-SHA256')
    .update(securedInput)
    .sign(privateKey)
    .toString('base64')
  return `${securedInput}.${signature}`
}

If I benchmark the following code with like a ~600byte header + payload combined locally, I get:

50000 RSA-SHA256 iterations took 14711.183667ms (0.29422367334ms per)

I have some benchmarks that have a node.js instance doing 1k requests per second with an express server without this crypto call. When we throw the crypto call in, the instance starts failing to respond to health checks and goes down to 100 requests per second.

I realize how vague all of this is, but I guess my overall question is: what changes can be made to the crypto.sign()call (and probably other crypto calls) to not block the same thread/event loop that accepts / receives / responds to network requests on a bound server?

Are async crypto calls on the roadmap? I could understand the argument to not async a call that takes 0.3ms on average, but I also don't know how else to offload the crypto signing from the main event loop.

[mscdex]

Duplicate of #678.