Limit for number of the eventing functions

Is there limit or recommended amount of eventing functions?
I have 10 eventing functions, 9 out of which are deployed. When I deployed 9th function, a warning message showed up:

Why do I see this message and what are recommended actions/standards?
Thank you

@evgeniya.bell It really depends on the work load (#of events-per-second to be processed, complexity of the handler JS code, #of bucket/n1ql/timer ops generated by handler JS code etc.). A general rule of thumb is to have total number of workers across all eventing functions[1] to be equal to the number of cores available on the machine[2]. We show this warning when [1] exceeds [2]. Hope this helps

@jeelan.poola We have 3 eventing machines with 12 cores each. I thought I would get to 36 executions before any warning.

Hi @evgeniya.bell - every handler runs on each eventing node, as we shard the data across the eventing nodes (rather than assigning some handlers to some eventing nodes, and having all nodes receive all data). So the UI warning looks at number of cores and number of handlers only, and not the number of nodes.

The purpose of the warning is to basically draw attention to the need to do sizing exercise. There is no hard limit that number of workers must be less than number of cores. When running handlers that have high latency (ex: making a curl call to outside world), it is common to have many more workers than number of cores.

As we don’t know beforehand what the handler code is doing, or how much mutation workload is expected, the warning uses this rudimentary approach to draw attention to sizing. We will change the text of the warning to be less confusing (and merely state that a sizing exercise should be performed) to avoid further ambiguity, MB-33624.