A function is the basic unit of management and operation in SCF, which usually consists of a series of configuration items and executable code/packages. You can trigger a function through APIs. You can also pass different events to a function through different triggers to trigger it for event processing.
A function resource must belong to a certain region. For regions supported by SCF, see Billing Overview.
A function resource must be created under a certain namespace in a certain region. Each region has a
default namespace. You can also create namespaces, whose names cannot be modified after creation.
It is the unique identifier of a function, must be unique under the same namespace, and cannot be modified after creation.
SCF supports two function types: event-triggered function and HTTP-triggered function.
SCF uses the UTC time by default, which you can modify by configuring the
TZ environment variable. After you select a time zone, the
TZ environment variable corresponding to the time zone will be added automatically.
Execution environment of the function code. Currently, SCF supports Python, Node.js, PHP, Java, Go, Custom Runtime, and image deployment.
The execution method specifies the starting file and function while invoking the function. There are three ways as follows:
Note that FileName does not include the file name extension, and FunctionName is the name of the entry function. Make sure that the file name extension matches the programming language. For example, for Python programming, the file name extension is
.py, and for Node.js programming, the file name extension is
It is used to record information such as the purpose of the function, which is optional.
In addition to the above configuration items, you can also modify the following configuration items for function execution by editing the function configuration in the console or updating function configuration:
The computing power supported by SCF includes CPU and GPU.
It sets the specifications of resources, such as different memory sizes for CPU and different card types for GPU.
Maximum initialization duration of the function between 3 and 300 seconds (90 seconds for image deployment-based functions and 60 seconds for other functions by default).
- The function initialization phase includes the preparations of function code, image, layer, and other relevant resources and execution of the main process code of the function. If your function has a larger image or complex business logic, increase the initialization timeout period appropriately.
- The initialization timeout period only takes effect in the scenario where the triggered instance is cold started for invocation.
- The client waiting time is better to be slightly larger than the sum of the initialization timeout period and the execution timeout period.
Maximum execution duration of the function between 1 and 900 seconds (3 seconds by default).
It can be defined in the configuration and obtained from the environment when the function is executed. For more information, see Environment Variables.
It grants the corresponding permissions of the policy contained in it to the function. For more information, see Role and Authorization. For example, to execute the action of writing an object into COS in the function code, you should configure an execution role with the permission to write COS.
It delivers function invocation logs to the specified log topic. For more information, see Log Search Guide.
It configures the function network access permissions. For more information, see Network Configuration Management.
After it is enabled, the function can access resources of the mounted file system. For more information, see Mounting CFS File System.
The execution configuration includes async execution, status tracking, and async execution event management. For more information, see Execution Configuration.
Async invocation configuration: You can use this configuration item to set the retry policy for async invocation. You can also configure the dead letter queue to collect error event information and analyze the failure cause.
After it is enabled, SCF will report the basic execution duration of the function to the specified APM system. You can also instrument the function code for custom reporting. This helps you better track and monitor the execution of the function.
In SCF use cases, DNS delays may cause function execution timeouts, affecting the normal business logic. In case of frequent function invocations, the resolution of the DNS server may exceed the frequency limit, which also leads to function execution failures. SCF provides the DNS cache configuration to solve these problems, which can improve the DNS efficiency and mitigate the impact of various factors such as network jitter on the DNS success rate. For more information, see DNS Caching Configuration.
Function trigger-related operations include:
Contact our sales team or business advisors to help your business.
Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.
Was this page helpful?