How to Benchmark and Optimize Tencent Cloud Serverless Functions for Real‑World Performance

Stress Test Plan

We used Tencent's WeTest tool, which provides a fairly complete configuration and reporting interface, to benchmark the Serverless functions. The tool limits request intervals to a minimum of one minute, which prevents pure cold‑start testing, but each stage automatically ramps up the number of users, indirectly exposing cold‑start latency when response times spike.

WeTest link: https://wetest.qq.com

Testing up to 200 concurrent users is straightforward; higher concurrency requires domain verification by placing a key file in the domain root. Because the automatically generated API‑gateway URL includes a /release/ path, the key cannot be placed at the root, so a custom domain is needed.

After feedback, Tencent added this requirement to their roadmap. In the meantime we borrowed a sub‑domain to continue testing.

Note: the domain must be registered with Tencent Cloud. Bind a sub‑domain via CNAME to the API‑gateway domain. If HTTPS is required, obtain a certificate (free options allow up to 20 per primary domain) and upload it to Tencent Cloud.

Evaluation and Optimization

We selected a simple CGI that performs a single database query to compare the original Node service with the Serverless version. Load was increased gradually.

At around 200 concurrent users the success rate dropped to just over 80%.

Problem Analysis

Log inspection revealed that, although Serverless can theoretically scale infinitely, actual limits are imposed by the allocated resources.

Optimization Options

Contact Tencent Cloud to request higher limits and pre‑allocate a resource pool, then re‑run the stress test.

The success rate improved, but average latency and the 90th‑percentile remained high due to a few long‑duration requests.

Further Problem Analysis

We broke down the long‑latency requests:

Cold start with a resource pool: code download and decompression take about 2.5 s + 2.4 s, up to ~3 s including network download.

Function execution (hot start): 70 ms ~ 115 ms, with path latency ranging from 5 ms to 600 ms.

Additional observations:

Setting instance retention (keeping a warm process) yields the greatest reduction in cold‑start latency.

Adjusting the size of the resource pool also lowers cold‑start time.

Reducing the code package size (e.g., from 58 MB to 32 MB) by extracting rarely used libraries into separate functions further improves performance.

Optimization Measures

Enable instance retention to keep a warm process ready.

Configure an appropriate resource‑pool size.

Split large, infrequently used libraries into separate functions, reducing the main package size.

After these changes, the longest requests improved, but average latency and the 90th‑percentile were still pulled up by occasional high‑latency outliers.

Overall, the optimized Serverless functions now meet the response‑time requirements for real‑time scenarios.

User‑Side Comparison

We compared real‑user latency between Serverless (red) and the original Node server (yellow).

Problem Analysis

On May 5th we optimized Serverless by simplifying requests, removing a pre‑flight OPTIONS request, and adding dns‑prefetch. The remaining ~100 ms gap is due to additional initial TCP connection and SSL handshake time, which the Node server avoided because the page and API share the same origin.

Clearing sockets (chrome://net‑internals/#sockets) reproduces the gap.

Deploying the function in Guangzhou reduced the latency compared to the Shanghai deployment when testing from Shenzhen, confirming that geographic proximity matters.

Serverless and API‑gateway are region‑locked; multi‑region deployment is planned.

Proposed Mitigation

We selected a simple proxy solution (rightmost in the diagram) and added preconnect headers to reduce TCP handshake and SSL time. <link rel="preconnect" href="//example.com"> Preconnect compatibility chart and before/after screenshots show a clear reduction in initial connection and SSL latency, especially on slower networks.

Summary

After optimization, Serverless cloud functions achieve acceptable response performance for instant‑return scenarios. Monitoring at the API‑gateway level (excluding network and handshake time) shows significant improvements.

Key takeaways:

Use a reliable stress‑test tool (WeTest) and supplement with custom scripts, browser network analysis, and real‑user testing.

Cloud‑side optimizations: increase limits, allocate dedicated resource pools, enable instance retention, and plan for multi‑region access.

Code‑side optimizations: streamline code, split rarely used features, reuse resources (e.g., DB connections), and keep functions warm.

Function lifecycle optimization steps include instance reuse, pre‑creating containers, caching hot code at node‑level and data‑center level, and predictive scaling via machine learning.