This topic describes the background information, scenarios, benefits, and limits of using a single instance to concurrently process multiple requests. This topic also describes how to set the request concurrency in a single instance in the Function Compute console.

Background information

Function Compute calculates fees based on the execution duration of requests by an instance. If the database access latency is 10 seconds and three requests are processed by three instances, the total execution duration of the requests by the three instances is 30 seconds. If the three requests are concurrently processed by one instance, the total execution duration of the requests by the instance is 10 seconds. To help you save costs for instance usage, Function Compute allows you to concurrently process multiple requests by using a single instance. You can set the InstanceConcurrency parameter to specify the number of requests that can be concurrently processed by an instance. The following figure shows the differences between how requests are concurrently processed by a single instance and by multiple instances.

instanceconcurrency
In the preceding figure, three requests need to be processed at the same time.
  • If the InstanceConcurrency parameter is set to 1, each instance can process one request at a time. Therefore, Function Compute needs to create three instances to process the three requests.
  • If the InstanceConcurrency parameter is set to 10, each instance can process 10 requests at a time. Therefore, Function Compute needs to create only one instance to process the three requests.
Note The default value of the InstanceConcurrency parameter is 1. A value of 1 indicates that a single instance can process only one request at a time. If you set the InstanceConcurrency parameter to a value greater than 1, Function Compute creates a new instance only when the number of requests to be concurrently processed by the existing instance exceeds the specified value.

Scenarios

If a function spends a large quantity of time waiting for responses from downstream services, we recommend that you use a single instance to concurrently process multiple requests. Resources are generally not consumed when requests are waiting for responses. If you use a single instance to concurrently process multiple requests, costs can be reduced.

Benefits

  • Reduces the execution duration and costs.

    For example, for functions that require I/O operations, you can use a single instance to concurrently process multiple requests. This reduces the number of instances that are used to process requests to reduce the total execution duration of requests by the instances.

  • Shares the status among requests.

    Multiple requests can share the connection pool of a database in one instance to minimize the connections between requests and the database.

  • Reduces the frequency of cold starts.

    Fewer instances need to be created because one instance can process multiple requests. This reduces the frequency of cold starts.

  • Reduces the number of IP addresses used in a virtual private cloud (VPC).

    For a fixed number of requests to be processed, the number of required instances is reduced if each instance can process multiple requests. This reduces the number of IP addresses used in the VPC.

    Notice Make sure that the vSwitch associated with your VPC has at least two available IP addresses. Otherwise, the service may be unavailable, leading to request errors.

Impacts

If you set the InstanceConcurrency parameter to a value greater than 1, the differences from a value of 1 for the InstanceConcurrency parameter lie in the following aspects:

  • Billing
    • A single instance that processes a single request at a time
      An instance can process only one request at a time. The billing duration starts when the first request starts to be processed and ends when the last request is processed. instanceconcurrency=1
    • A single instance that concurrently processes multiple requests

      For a single instance that concurrently processes multiple requests, Function Compute calculates fees based on the execution duration of the requests by the instance. The billing duration starts when the first request starts to be processed and ends when the last request is processed.

      instanceconcurrency

    For more information, see Billing.

  • Concurrency limit

    By default, Function Compute supports a maximum of 300 pay-as-you-go instances in a region. The maximum number of requests that can be concurrently processed in a region is calculated based on the following formula: 300 × Value of the InstanceConcurrency parameter. For example, if you set the InstanceConcurrency parameter to 10, a maximum of 3,000 requests can be concurrently processed in a region. If the number of concurrent requests exceeds the maximum number of requests that Function Compute can process, the ResourceExhausted error is returned.

    Note If you want to increase the maximum number of pay-as-you-go instances in a region, you can contact Function Compute engineers. For more information, see Contact Us.
  • Logging
    • For a single instance that processes a single request at a time, if you specify X-Fc-Log-Type: Tail in the HTTP header when you invoke a function, Function Compute returns the function logs in the X-Fc-Log-Result field that is in the response header. For a single instance that concurrently processes multiple requests, the response header does not include function logs because the logs of a specific request cannot be obtained among concurrent requests.
    • For the Node.js runtime, the console.info() function is used to return the ID of the current request in the log. If an instance concurrently processes multiple requests, the console.info() function cannot display the correct IDs of all the requests. All the request IDs are changed to req 2. The following sample log is displayed:
      2019-11-06T14:23:37.587Z req1 [info] logger begin
      2019-11-06T14:23:37.587Z req1 [info] ctxlogger begin
      2019-11-06T14:23:37.587Z req2 [info] logger begin
      2019-11-06T14:23:37.587Z req2 [info] ctxlogger begin
      2019-11-06T14:23:40.587Z req1 [info] ctxlogger end
      2019-11-06T14:23:40.587Z req2 [info] ctxlogger end
      2019-11-06T14:23:37.587Z req2 [info] logger end
      2019-11-06T14:23:37.587Z req2 [info] logger end                    
      In this case, the context.logger.info() function can be used to display logs. This ensures that the correct ID of a request is returned. Sample code:
      exports.handler = (event, context, callback) => {
          console.info('logger begin');
          context.logger.info('ctxlogger begin');
      
          setTimeout(function() {
              context.logger.info('ctxlogger end');
              console.info('logger end');
              callback(null, 'hello world');
          }, 3000);
      };                   
  • Troubleshooting

    When an instance concurrently processes multiple requests, an unexpected process quit caused by a failed request can affect other concurrent requests. Therefore, you must compile troubleshooting logic to prevent impacts on other requests. The following example shows the sample Node.js code:

    exports.handler = (event, context, callback) => {
        try {
            JSON.parse(event);
        } catch (ex) {
            callback(ex);
        }
    
        callback(null, 'hello world');
    };                    
  • Shared variables

    When an instance concurrently processes multiple requests, errors may occur if multiple requests attempt to modify the same variable at the same time. You must use the mutual exclusion method to prevent variable modifications that are not safe for threads when you define your functions. The following example shows the sample Java code:

    public class App implements StreamRequestHandler
    {
        private static int counter = 0;
    
        @Override
        public void handleRequest(InputStream inputStream, OutputStream outputStream, Context context) throws IOException {
            synchronized (this) {
                counter = counter + 1;
            }
            outputStream.write(new String("hello world").getBytes());
        }
    }                    
  • Metrics
    After you set the instance concurrency for a function, you can log on to the Function Compute console and check that the number of used instances is reduced in the On-demand Instances monitoring chart. Instance monitoring chart

Usage limits

Item Description
Supported runtime environments
  • Node.js
  • Java
  • Custom Runtime
Value range for the InstanceConcurrency parameter 1 to 100
Function execution logs provided in the X-Fc-Log-Result field in the response header Not supported if the InstanceConcurrency parameter is set to a value greater than 1

Prerequisites

Create a function

Procedure

You can set the InstanceConcurrency parameter when you update a function. For more information, see Update a function. update-instanceconcurrency

If you use provisioned instances, the function in provisioned mode can concurrently process multiple requests. For more information, see Auto Scaling (including reserved resources).

References

For more information about how to use the SDK for Node.js to set the concurrency, see Specify the instance concurrency.