In-Depth Understanding of Cloud Function

In cloud functions, the runtime behavior of Node.js differs somewhat from that of Node.js running locally.

Startup Time

There are two types of startup for cloud functions:

• Cold start: Requires the platform to allocate computing resources, load the code, and start the Node.js process, which is time-consuming;
• Hot start: Both the function instance and the execution process are reused (known as "instance reuse" mentioned below), which is very fast.

If a cloud function is not invoked within a certain period (tens of minutes), the platform will reclaim the allocated compute resources. Compute resources will not be reallocated until the function is invoked again, in which case a cold start occurs.

If consecutive requests are made to the cloud function, the initialized instances from a cold start will be reused and can begin computation very quickly, which constitutes a hot start.

Tip

CloudBase automatically schedules and adjusts the number of instances based on the long-term access patterns of your cloud functions, ensuring optimal performance while saving your resources.

Instance Reuse

Consider the following cloud function:

let i = 0;
exports.main = async (event = {}) => {
  i++;
  console.log(i);
  return i;
};

When the cloud function is invoked for the first time, the return value is 1, which is as expected.

However, if this cloud function is invoked consecutively, the return value may increment from 2 or revert to 1. This is the result of instance reuse:

• During a Hot start, the Node.js process executing the function is reused, and the process context is preserved, so the variable i is incremented.
• During a Cold start, the Node.js process is brand new, and the code executes completely from the beginning, returning 1 at this point.

Therefore, developers should ensure that cloud functions are stateless and idempotent when writing them, meaning that the execution of a cloud function does not rely on residual information from previous executions in the runtime environment.

Time Zone

The default time zone in cloud functions is UTC+0, so obtaining local time within the function will result in an 8-hour difference from Beijing Time.

Define the environment variable TZ to change the time zone of the function runtime. For example, setting TZ to Asia/Shanghai specifies the function's time zone as Beijing Time.

For more information on time zones, refer to: Time Zone Database.

Tip

When processing time on the server side (including databases and cloud functions), the use of time-zone-dependent local time should be avoided, and absolute values like Unix timestamps should be used instead. This approach prevents numerous issues arising from time zone differences between the server and client sides.

Asynchronous Behavior of Node.js 8

Consider the following code:

exports.main = async (event = {}, context) => {
  setTimeout(() => {
    console.log("rid: ", context.request_id);
  }, 0);
  return "ok";
};

When invoked locally, the function returns "ok", and the printing of the requestId can be seen subsequently.

But if you run this code in a Node.js 8 cloud function, the function still returns "ok", but the content printed by the asynchronous function in setTimeout will not be seen in the call logs for this invocation, for example:

If you invoke it a second time, you may see the print from the previous setTimeout in the invocation logs:

This is a point that confuses many developers.

For asynchronous functions, after the main process (e.g., await main(event, context) in the example) completes execution, the function instance process will be frozen, and all asynchronous tasks within the process will pause execution until the process is invoked again.

On the other hand, if the function instance process is not reused for some reason (e.g., when the function code is updated), the code in this asynchronous process will never be executed.

Tip

Developers should not place critical code in the asynchronous process of Node.js 8 cloud functions. If you want critical code to run stably, place it in the main process of the function, or use cloud functions with Node.js version 10 or above:

Example

The asynchronous nature of Node.js 8 cloud functions may result in some unexpected behaviors, for example:

The Mini Program wx-server-sdk provides the getWXContext method to obtain contextual information (appId, openId, unionId) for functions, facilitating developers. This method essentially reads several parameters from environment variables.

If this method is used to obtain openId or unionId in an asynchronous process, it may cause an identity drift exception.

Consider the following code:

const cloud = require("wx-server-sdk");

exports.main = async (event) => {
  console.log("openid a: ", cloud.getWXContext().OPENID);
  setTimeout(() => {
    const { OPENID } = cloud.getWXContext();
    console.log("openid b: ", OPENID);
  }, 0);
};

Suppose two different users access the function via the Mini Program, where user A's openid is 1111 and user B's openid is 2222.

Their logs for the two invocations will be:

We can see that the first invocation printed user A's openid, which is as expected, but the logic in the asynchronous process was not executed during the current invocation.

During the second invocation, the function instance process is reused, and the asynchronous logic generated by the first invocation continues to run, printing user B's openid. However, this execution actually belongs to the asynchronous process initiated by user A's function invocation.