Performance Evaluation and Optimization of Tencent Cloud Serverless Functions

The article is authored by Long Yongxia, a senior front‑end engineer at Tencent, who is currently working on the online‑education platform Penguindudu. He has a strong interest in front‑end performance optimization and full‑stack development.

Serverless cloud functions promise high concurrency and theoretically unlimited auto‑scaling, but they suffer from cold‑start latency. The author investigates the real‑world performance of Tencent Cloud Serverless functions by migrating an existing Node.js service to a Serverless environment and comparing the two.

Load‑testing Plan

The team used Tencent’s internal tool “WeTest” (wetest.qq.com) for load testing. The tool limits request intervals to one minute, which makes pure cold‑start testing difficult, but it can still reveal cold‑start impact through spikes in latency. For tests exceeding 200 concurrent users, domain verification is required, which is problematic because the automatically generated API‑gateway URL includes a /release/ path that cannot host the verification key. The team worked around this by using a sub‑domain bound via CNAME to the API‑gateway domain and, if needed, uploading an SSL certificate.

Evaluation and Optimization

A simple CGI that performs a single database query was chosen for comparison. During tests, success rates dropped around 200 concurrent users. The analysis of logs showed three main latency contributors:

Function execution time (70‑115 ms) and path latency (5‑600 ms).

Cold‑start overhead (≈20‑50 ms).

Occasional >5 s delays caused by path or single‑node processing limits.

After code optimizations, the highest‑latency requests improved, but average and 90th‑percentile latencies remained high due to outliers.

Further Analysis

Additional custom Python scripts were written to reproduce WeTest scenarios (geographically distributed, step‑wise concurrency increase, 30 s per stage). Communication with the WeTest team led to experiments with long‑connections, short‑connections, multiple IP sources, and disabling log printing. The results showed average latency under 200 ms for 200 concurrent users, meeting the target.

The main cause of remaining latency differences was identified as “network connection time”. Long‑connection tests and multi‑IP tests reduced latency significantly. Moreover, Serverless requests incurred extra Initial‑connection and SSL handshake times compared with the original Node.js service, which ran on the same domain and thus avoided these costs.

Geographic factors also mattered: the Serverless function was deployed in Shanghai while tests were run from Shenzhen, leading to higher latency. Deploying a function in Guangzhou reduced the gap, highlighting the importance of proximity and the role of Tencent’s Secure Tencent Gateway (STGW) for near‑edge access and SSL acceleration.

Currently, Serverless functions and API gateways are region‑locked; cross‑region access is not supported. The product team has added multi‑region deployment to the roadmap. As an interim solution, the team adopted a simple proxy architecture (the right‑most option in the diagram) and leveraged <link rel="preconnect" href="//example.com"> to reduce TCP handshakes and SSL time.

Conclusion

The performance of Tencent Cloud Serverless functions now meets the requirements for real‑time response scenarios. The article summarizes the testing methodology, problem analysis, and concrete optimization measures, and outlines future improvements such as configurable concurrency limits, cold‑start mitigation, instance retention policies, architectural upgrades, and near‑edge access.