Contents：
Container Model of the Function Runtime
SCF will execute a function on your behalf when an event is triggered, allocate resources based on your configuration information (such as memory size), and launch and manage the container (i.e., the execution environment of the function).
Container Launch takes some time, which adds some delay to each function call. However, delays are usually detected only when the function is called for the first time, when the function is updated, or when the function is not called for a long time. In order to minimize the delay of container Launch, the platform will try to reuse the container for subsequent calls. After calling the function, the container will remain for a period of time according to the actual situation of the platform, which is expected to be used for the next call. Calls within this period of time will reuse the container directly.
The significance of the container reuse mechanism lies in:
- All declarations outside the Execution method Part in your code remain initialized and can be reused directly when the function is called again.
- Each container in
/tmpDirectory provides some disk space. The contents of this directory are retained when the container is retained, providing a temporary cache that can be used for multiple calls. It is possible to use the contents of the disk directly when the function is called again. You can add extra code to check whether such data is in the cache.
Do not assume that the container is always reused in the function code, because reuse is related to the single actual call, and it cannot be guaranteed whether a new container will be created or an existing one will be reused.
Temporary Disk Space
During the execution of the SCF function, it has a temporary disk space of 512MB. /tmp The user can read and write to the space in the execution code, or create a child Directory, but this part of the data may No Reserved after the function execution is complete. Therefore, if you need to persistently store the data generated during execution, please use COS or external persistent storage services such as Redis/Memcached.
Call Types
The SCF platform supports both sync and async calls of functions. The call type is independent of the configuration of the function itself and can only be controlled when the function is called.
- Sync call will wait for the execution result of the function after the call request is sent.
- Async call will only send the request and get the request ID of the current request, but not wait for the result.
In the following call scenarios, you can freely define the call type of the function:
If you need to make a sync call, pass in the parameter invokeType=RequestResponse To the InvokeFunction API; if you need to make an async call, pass in the parameter invokeType=Event .
- The SCF function is manually called (using API or TCCLI) for testing.
However, if you use another Tencent Cloud service as the event source, the call type of the cloud service is predefined, and you cannot freely specify the call type in this case.
Usage Restrictions
For the restrictions on function usage quotas and related environments, see Quota Limits .
Function Concurrency
The amount of function concurrency is the number of executions of the function code in any given period of time. For the current SCF function, the request is executed once each time an event is published. Therefore, the number of events (i.e., requests) published by the trigger affects the amount of function concurrency. You can use the formula below to estimate the total number of concurrent function instances.
Requests per second * function execution duration (in seconds) For example, for a function that handles COS events, if the function takes an average of 0.2 seconds (i.e., 200 milliseconds) for execution and COS publishes 300 requests per second to the function, then 300\ * 0.2 = 60 function instances will be generated simultaneously.
Concurrency Restrictions
Currently, by default, SCF has a certain limit on the concurrency of each function. You can check the Quotas and restrictions Understand the concurrency limits of the current function. You can use Contact Us To increase this number.
If a call causes the function concurrency to exceed the default limit, the call will be blocked and not executed by SCF. Restricted calls are handled differently depending on the function call type:
- Sync call: If the function is restricted when called synchronously, a 429 error will be returned directly.
- Async call: If the function is restricted when called asynchronously, SCF will automatically retry the restricted event at a fixed frequency for a certain period of time.
Retry Mechanism
If your function fails due to internal restrictions such as exceeding the maximum number of Concurrence or insufficient resources within the platform, an error will be returned directly if your function is called synchronously (see Concurrence for restrictions). If the function is called asynchronously by an internal cloud service, the call will automatically enter a retry queue and SCF will automatically retry the call.
Execution Environment and Available Libraries
The current SCF execution environment is built based on the following:
- Standard CentOS 7.2
If you need to include executable binaries, dynamic libraries, or static libraries in your code, make sure that they are compatible with this execution environment.
Based on different language environments, there are base libraries and additional libraries installed for the corresponding language in the SCF execution environment. You can view the additional libraries installed in the environment in the descriptions of each language:
