Web Functions Request Concurrency: Single vs Multi-Concurrency Performance and Cost Analysis

Web Functions (Web Function) are a type of cloud function that, unlike Event Functions, support native HTTP/WebSocket protocols and can run any web framework without modification, allowing traditional web projects to be deployed as serverless functions with the same development experience.

Since its launch in June 2021, Web Functions have enabled tens of thousands of legacy web projects to migrate to serverless infrastructure. As usage expands, limitations of the default single-request concurrency model have become apparent.

1. Single Request Concurrency

By default, each function invocation is handled by a dedicated concurrency instance. If all instances are busy, a new instance is allocated. This model avoids typical concurrency issues such as thread safety, blocking calls, and exception handling.

However, many web workloads are I/O‑intensive (e.g., database calls, downstream service requests). In such cases, the instance spends most of its time waiting (iowait), leading to two problems:

Wasted compute resources, especially noticeable with long‑lived WebSocket connections.

Higher billing, because each concurrent request is processed by a separate instance, increasing overall cost compared with traditional containers or VMs.

2. Multi‑Request Concurrency

Web Functions now support a multi‑request concurrency mode, which can be enabled and configured per business needs. Two sub‑modes are available:

Custom Static Concurrency : Limits the number of concurrent requests per instance to a user‑defined value (2‑100). Increasing concurrency raises CPU and memory usage, so testing is recommended.

Intelligent Dynamic Concurrency : Dynamically schedules more requests to the same instance when load permits (to be released in a future update).

3. Performance Test (Beijing region, 512 MB instance)

Test scenario: simulate a 500 ms response time per request, 100 concurrent requests, total 50 000 requests.

Without Multi‑Concurrency

• Required 60 instances • Max response time: 4 177 ms • Billing memory‑time: 12 500 GB·s

Result: Cold‑start of many instances caused a long tail latency; most requests after warm‑up had normal latency.

With 100‑Request Multi‑Concurrency Enabled

• Required 1 instance • Max response time: 723 ms • Billing memory‑time: 150 GB·s

Result: Only a few requests waited for cold‑start; the majority were processed by the single warmed instance, dramatically reducing latency and cost.

4. Advantages of Multi‑Concurrency

(1) Lower Cost

When single concurrency is used, each request’s execution time is billed separately, leading to higher memory‑time consumption. With multi‑concurrency, overlapping execution periods are billed only once, saving up to 98.8% of costs in I/O‑intensive scenarios.

(2) Performance Boost

Multiple requests share the same instance, allowing reuse of database connection pools and reducing downstream pressure. Fewer instances also mean fewer cold starts, further decreasing response latency.

For more details, see the Cloud Function product page and the Web Function multi‑concurrency documentation:

https://cloud.tencent.com/product/scf

https://cloud.tencent.com/document/product/583/71688