How to deploy multi pool manager ? about fission

[soamvasani]

First, it's worth noting that poolmgr is only on the cold-start request path, so it won't need to scale as much as other components, such as the router. Also, most of its work is async (waiting for fetcher, waiting for the function to be loaded, waiting for pods to be ready, etc.), so we should get pretty far with just one instance.

When we do reach its limit, we could persist the instanceId in etcd; multiple instances would then operate on the same generic pool.

[hjianhao]

it seems like there is a single point bottleneck in poolmgr, because every warm request need to call go fh.tapService(serviceUrl), and tapService call err := fh.poolmgr.TapService(serviceUrl) to call poolmgr's API, so when massive function call coming, especially after the router scale out, poolmgr must be the bottleneck.

[soamvasani]

Yeah... in hindsight I'm not too happy about this tapService design. We should probably have pods just destroy themselves when they're idle, and have poolmgr and router deal with the edge cases that come up when we do that.

Though note that the call to tapService is async, so the warm request latency overhead doesn't directly include the poolmgr tapService latency.

[hjianhao]

Yeah, I agree with you. It maybe a better method that run-time framework of each language recording the last calling time, and check it in a short period, when it's idle, then exit.

[soamvasani]

There's room for improvement here but no actual bugs, so I'm going to close this for now. I'd like to actually see how far the current design can get before making it more complex. (The current design also has the nice property that language-specific code remains simple.)