Question about data effectiveness about data-release

[jokerwyt]

Do you allow functions to run in the background even if there is no request? That's an approach only suitable for cooperative cloud but the paper does not mention it.

[ajoosen]

Hi,

Thank you for your question.

In the Private Trace, CPU and memory usage are both calculated at the pod level using Prometheus, meaning that metrics will be collected at a certain frequency while the pod is alive.

There are two types of pod allocations. There are "on-demand" instances and "reserved" instances. Reserved instances are always on and always running the code for that function, regardless of the number of function requests received. If the current reserved function instances cannot handle incoming requests, the platform will generate more on-demand function instances. Since the process running the function code is always running in reserved instances, this contributes to the CPU usage, even when there is no request at that specific time.

For function 10, we can see that the number of function instances is 6 for almost the entire day, while the number of requests varies between 4 and 71 requests per minute. Although we do not have the exact information about whether these are on-demand or reserved instances, the fact that the number of instances remains the same suggests these are likely to be reserved instances.

Therefore, we do not recommend trying to calculate the CPU usage in terms of the function delay (execution time) of requests.

Other than that, ultimately the CPU usage of a function depends on its internal logic, and we have no information about the internal behaviour of particular functions.

[jokerwyt]

Hi,

Thank you for your question.

In the Private Trace, CPU and memory usage are both calculated at the pod level using Prometheus, meaning that metrics will be collected at a certain frequency while the pod is alive.

There are two types of pod allocations. There are "on-demand" instances and "reserved" instances. Reserved instances are always on and always running the code for that function, regardless of the number of function requests received. If the current reserved function instances cannot handle incoming requests, the platform will generate more on-demand function instances. Since the process running the function code is always running in reserved instances, this contributes to the CPU usage, even when there is no request at that specific time.

For function 10, we can see that the number of function instances is 6 for almost the entire day, while the number of requests varies between 4 and 71 requests per minute. Although we do not have the exact information about whether these are on-demand or reserved instances, the fact that the number of instances remains the same suggests these are likely to be reserved instances.

Therefore, we do not recommend trying to calculate the CPU usage in terms of the function delay (execution time) of requests.

Other than that, ultimately the CPU usage of a function depends on its internal logic, and we have no information about the internal behaviour of particular functions.

Got it. Thanks for your reply and the nice dataset.