SCF now provides concurrency quota management capabilities at three levels. With this feature, you can get greater permissions to control function concurrency to adjust the concurrency quickly based on your business needs instead of applying for concurrency quota.
The default function concurrency limit is set to 300 by default. For infrequent businesses with low function usage, the 300 concurrent instances were generally sufficient. However, in cases where high concurrency was required, such as business surges and large-scale campaigns, you needed to submit a ticket to apply for an increase in the concurrency quota. This scheme has the following three challenges:
Every time your business surged, you needed to contact Tencent Cloud to apply for an increase in the function quota, which was time-consuming.
Your business growth might be restricted during the application processing time.
The application might be rejected due to insufficient business scale during the evaluation, leading to reapplication and making the process inefficient.
This document describes the concurrency management feature in detail and provides configuration suggestions for a variety of use cases.
SCF provides the following concurrency management options:
You can customize the concurrency quota for individual functions.
The concurrency quota is configured at the account level, instead of the function level.
Each account is allocated with a concurrency quota, which is shared by all functions under the account. You do not need to separately apply for a quota for high-concurrency functions.
Each account is allocated with a concurrency quota of 128,000 MB, which allows 1,000 function instances with the 128 MB specification to run concurrently. You don’t need to apply for a quota increase to sustain your business growth. See below for the trend of concurrency usage:
Relationship between memory and concurrency quota
Concurrency quota is calculated by the memory. A function with a higher memory configuration occupies a larger share of the quota during concurrent execution, while a function with a smaller memory configuration memory occupies a smaller share of the quota during concurrent execution.
Since the resource usage billing item of the SCF service is highly related to the configured memory of functions, if you need to control the quota through the memory configuration, we recommend you select an appropriate function memory value for your business, which can effectively control the overall costs. The memory changes are as shown below:
Concurrency use cases
If multiple businesses under your account use SCF for support at the same time, you should schedule the concurrency quotas of functions as needed and make reasonable settings according to different business characteristics. The following analyzes the types, characteristics, and requirements of different businesses:
There are peak hours and off-peak hours.
A fast page load speed is required and a certain fault tolerance is allowed.
The operation is stable with little fluctuation.
Delays, fluctuations, and failures are unacceptable.
Tasks are scheduled and occasional.
There is no need to pay much attention as long as the tasks run normally.
Video processing business
The concurrency is not high, but the computation is complicated and time-consuming.
On-demand scheduling is acceptable as long as tasks can automatically restore upon failure.
According to different business characteristics, fault tolerance limits, business fluctuations, and delay requirements, different configurations can be made for different use cases as recommended below:
Video processing business
Frontend businesses require a fast page load speed and have peak hours and off-peak hours. You can configure the provisioned concurrency quota (e.g. 60% of the maximum usage), and leave out the reserved concurrency quota, so that the total quota can be fully utilized during peak hours. See below for the trend of concurrency usage:
Data processing businesses with little fluctuation but low fault tolerance, you can configure the reserved concurrency quota for the function, so that the quota is not shared by other businesses. See below for the trend of concurrency usage:
For OPS tasks that are not demanding and run regularly, you don't need to make any configurations; instead, you can simply use the account-level quota logic.
For video processing businesses that have a large amount of computation where tasks are queued up for on-demand processing, a certain reserved concurrency quota can be configured for functions, so that the businesses can run at the full concurrency quota and make the most of computing resources. See below for the trend of concurrency usage:
Reserved quota use case
The account-level quota is shared by multiple functions under the account. If multiple functions run simultaneously, functions whose concurrency is increased due to traffic/business surges may conflict with stable functions after they use up all the available quota.
For the above scenario, there are two solutions as follows:
In this case, you can configure the reserved quota. The execution stability of specific functions can be guaranteed by assigning a certain part of the quota to them.
You can also purchase a subscription package with a higher specification to get a higher concurrency quota and better sustain concurrency bursts caused by your business growth.
Configuring reserved quota
The following takes solution 1 (reserved quota configuration) as an example to describe how to use the reserved quota in detail.
Scenario: Function A and Function B are under the same account. Function A is used for flash sale H5 pages, and Function B is used for streamline data processing on the backend. Function B launches 300 concurrent instances first for normal business running, and Function A takes the rest 700 concurrency for promotion events. In this case, if a request surge comes to Function B, no more instances can be started due to the quota limit. You can configure the reserved concurrency to keep the balance between these two funcitons.
Sample configuration: To ensure the reliability of data processing, which is handled by Function B, you can set the reserved concurrency quota to 350 for Function B. Then, this quota will be assigned exclusively to Function B from the account level, and Function A can use 650 concurrent instances at most. Note that the concurrency of Function B cannot exceeds 350 even if there are still available resources within the account-level quota. The function quota changes are as shown below:
With the reserved quota,
The normal execution of a function is guaranteed, preventing losses caused by the function's inability to run due to other functions using the shared quota.
The max concurrency of a function is limited.
For functions in the development and testing phase, because of the small number of requests, low business pressure, and low concurrency, there is no need to configure the reserved quota, and it is fine to use the shared quota at the account level.
For functions that run stably, the concurrency is usually predictable with minimal fluctuations. Therefore, you can configure a reserved quota with a small margin to ensure that the quota will not be affected by sharing.
For functions used for operational activities where the concurrency may surge, you can increase the account-level quota to make full use of and support the business growth.
Currently, provisioned concurrency quota is set at the function version level, which is deducted from the concurrency quota at the account level or the provisioned concurrency quota at the function level.
By configuring provisioned concurrency quota, you can start the required number of concurrent instances, complete the instance initialization, and wait for events to occur in advance. Requests for the function will not have a cold start time, and they can be run directly in the instances that have already been prepared and initialized.
For delay-sensitive businesses (such as frontend SSR page response) or businesses with a long initialization time (such as the model loading process of AI inference), configuring provisioned concurrency can ensure better business operation.
Meanwhile, as the provisioned concurrency quota is not the upper limit of instance concurrency, when the business volume exceeds the maximum scale that the provisioned instances can sustain, the function will still launch more instances according to its provisioned concurrency quota or account-level quota to support the business operation. The function quota changes are as shown below:
Other usages of reserved concurrency quota
The restriction or shutdown of a business can also be implemented by configuring the reserved quota. In case of emergencies, such as vulnerability attacks and out-of-control loop invocations, in order to avoid major losses, you can set the reserved quota to a very small value to avoid running out of control or even to 0 to stop function execution. For more information, see Concurrency Management System. The configuration is as shown below:
Was this page helpful?