Worker pool model may not work well with lazy loading certificates about gokeyless HOT 6 CLOSED

Come to think of it, spawning goroutines introduces a memory leak risk - an attacker could send requests faster than we can process them, which would result in a large number of goroutines being spawned. The channel supplying the pool with jobs would eventually back up, at which point all of the spawned goroutines would be blocked on sending and unable to die. The reader goroutine would continue reading packets off the connection and spawning goroutines until the system ran out of memory.

from gokeyless.

I suppose that one approach would be to have a maximum number of outstanding requests (or even just a maximum number of outstanding key lookups) per connection and blocking if you reach that maximum.

from gokeyless.

I suppose that one approach would be to have a maximum number of outstanding requests

You could say that the number of workers in the pool is this parameter, so from the latency point-of-view a worker pool is optimal because we don't have to create new goroutines and wait for them to get scheduled.

From a throughput point-of-view: Assuming we want to handle 1,000 req/s (a huge number) and that different workers are truly parallel, then the most expensive operation needs to happen in less than 8 milliseconds. This sounds like a sufficient amount of to me.

If you want to add a metric that somehow measures "typical number of busy/idle worker threads", I think that would valuable for making sure we are using the right model. Although I imagine that 8 workers is more-than-sufficient for now.

from gokeyless.

You could say that the number of workers in the pool is this parameter, so from the latency point-of-view a worker pool is optimal because we don't have to create new goroutines and wait for them to get scheduled.

This is an interesting thought, although my concern would be that, just like the issue of generating random ECDSA values in the worker threads as opposed to in an idle thread, you'd run the risk that at the moment a request came in, all of the worker threads were in the middle of a long-running (IO-bound, in this case) computation, and so the latency would be high due to waiting for the first one to finish its computation and be ready to process the request.

from gokeyless.

If you want to add a metric that somehow measures "typical number of busy/idle worker threads", I think that would valuable for making sure we are using the right model.

I'm not sure how that'd be done, but I think it's a good idea.

from gokeyless.

This has proven to be a non-issue in practice

from gokeyless.