2020-11-01 07:43:31 UTC - Dominic Kim: I haven't followed up the changes but if I remember correctly, the step size also varies accordging to the hash value of each action. So the two actions which share the same home invoker would highly likely be scheduled to different invokers. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1604216611191400?thread_ts=1604106844.183200&cid=C3TPCAQG1 ---- 2020-11-01 07:48:49 UTC - Dominic Kim: But it did not mitigate the issue you described well in my experience. That was becuase the two are anyway sent to the home invoker first. Only if the home invoker is full, they would be sent to the next invoker. So once the home invoker becomes full, they are scheduled to the next invokers, but the capacity of the home invoker becomes available again, and they are scheduled to the home invoker again and eventually competing resources accordingly. And it repeatedly happened. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1604216929191600?thread_ts=1604106844.183200&cid=C3TPCAQG1 ---- 2020-11-01 16:57:34 UTC - Houman Kamali: Hi, I have a general question about cold/hot starts. Let’s say there are 100 parallel requests sent to OpenWhisk; 1. how does it decide whether it should spin up 100 containers and send each one request, or spin up 10 and send each 10 requests? 2. does hot container only work if the number of instances don’t change? 3. if each new container requires a cold start, how does it decide whether it’s faster to spin up 100 containers and process each request, or if it’s faster to spin only 10 and save time by avoiding cold start? (or does it even make such considerations?) Thanks! https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1604249854198100?thread_ts=1604249854.198100&cid=C3TPCAQG1 ---- 2020-11-01 16:59:21 UTC - Houman Kamali: @Rodric Rabbah Would be thankful if even pointed in a general direction e.g. where in the code this is implemented. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1604249961198200?thread_ts=1604249854.198100&cid=C3TPCAQG1 ---- 2020-11-01 23:25:00 UTC - Rodric Rabbah: The way to implement a webhook right now is at user level.
You can create an action which invokes the webhook. The sequence that action with your primary action. And invoke the sequence instead. (wsk action create —sequence). This is a useful feature to support intrinsically though. We’ve had some discussions about this in the past as part of the work on conductor actions. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1604273100201200?thread_ts=1604131976.191300&cid=C3TPCAQG1 ---- 2020-11-01 23:57:56 UTC - Rodric Rabbah: The loadbalancer’s job is to first allocate an invoker for each activation request. Then the scheduler in each invoker allocates a container for the request. The loadbalancer allocated an invoker by hashing the request details and then picking the invoker with the least load (outstanding queue depth). The invoker decides to reuse a container of its available (previous activation finished) otherwise it allocates a new container. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1604275076204600?thread_ts=1604249854.198100&cid=C3TPCAQG1 ---- 2020-11-01 23:59:32 UTC - Rodric Rabbah: There’s no explicit computation that dictates whether to wait or not in the invoker. Either a container is free and it’s used or it’s not and a new one created. One could add a predictor based on previous profiles to guide that part of the heuristic but it doesn’t exist today. https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1604275172206800?thread_ts=1604249854.198100&cid=C3TPCAQG1 ----
