How to Optimize Serverless Function Parameters for Cost and Performance

Parameter Configuration Dimensions

When tuning Serverless functions, three key dimensions should be considered:

Cost‑Performance Trade‑off – Increasing per‑instance concurrency reduces the number of instances and lowers cost, but excessive concurrency can cause resource contention and higher latency.

Function Logic Complexity – CPU‑bound workloads benefit linearly from larger instance specifications, while I/O‑bound workloads see diminishing returns as spec increases.

Impact on Underlying Compute Resources – Settings for instance concurrency, minimum instance count, and maximum instance count affect resource allocation, isolation, and overall platform elasticity.

Benchmark Findings

CPU‑intensive functions exhibit a clear linear relationship between instance specification (memory/CPU) and maximum throughput (maxTPS). Higher specs lower response time (RT) up to 4‑8 GB, after which marginal gains diminish.

I/O‑intensive functions show limited improvement in maxTPS and RT as specifications increase; performance plateaus even with high‑spec instances.

Evaluating Configuration Reasonableness

After an initial configuration, developers often discover cost overruns or performance gaps. Load testing validates settings. Alibaba Cloud Function Compute (FC) provides a free Performance Probing feature that estimates optimal concurrency and instance spec based on Little’s Law: Concurrency = AverageLatency × TargetTPS The probe runs on a single HTTP function instance and recommends the smallest spec and concurrency that satisfy a latency target.

Single‑Instance Performance Probing Workflow

Log in to the Function Compute console and select the target service.

Open the function’s Performance Probing tab and create a new probe task.

Enter the API endpoint details, execute the probe, and review the analysis report, which includes recommended instance specifications and optimal concurrency.

Only HTTP functions are supported, and the probe tests a single instance. Multi‑instance performance can be approximated by linearly scaling the single‑instance results.

Multi‑Instance Load Testing with PTS

Alibaba Cloud Performance Testing Service (PTS) offers a full‑stack load‑testing platform compatible with JMeter. The typical PTS workflow:

Navigate to the PTS console and choose Performance Testing > Create Scene .

Create a scene, add a pressure‑test node, and configure the target API URL.

In the Pressure Configuration tab, set auto‑increment mode (e.g., start 20 % at 500 VUs, increase 20 % each minute), maximum concurrency (e.g., 500), increment percentage (20 %), step duration (1 min), and total test duration (5 min).

Start the test; the console displays success rate, response time (RT), and transactions per second (TPS) in real time.

After completion, view the detailed report to analyze latency curves and QPS limits for each spec.

PTS supports up to millions of virtual users and provides free trial quotas for new users.

Practical Recommendations

Use the single‑instance probe to obtain the maximum QPS each spec can sustain for a given latency requirement.

Apply linear scaling to estimate multi‑instance capacity.

Combine probe results with historical traffic patterns to select the lowest‑cost spec that still meets SLA latency.

When reducing instance specs, verify that QoS (latency, error rate) remains within acceptable bounds.

Example Calculation

If the target end‑to‑end latency is 1000 ms, use the probe to find the smallest instance spec whose recommended concurrency yields a QPS that satisfies the latency constraint. The recommended spec and concurrency become the baseline for scaling the function.

Key Limitations

Performance probing is limited to HTTP‑triggered functions and single‑instance tests.

Multi‑instance performance assumes linear scaling; non‑linear behavior may require additional testing.

Reference Images