Why might throughput stop growing after more Pods are added?

The bottleneck may move to a shared cache, database, network, lock, or code path. HPA adds replicas but does not remove those shared constraints.

What did profiling surface in this story?

The published story focuses on Lock Wait Time and Socket I/O Read Time and combines them with APM and Redis state to locate frequent Redis calls in the code.

Can the load-test result be treated as a performance guarantee?

No. It records one code version, resource configuration, traffic model, and test environment. Every other workload requires its own validation.

Yingxiong Network: Kubernetes Load Tests & Profiling

Customer context

Yingxiong Network is an interactive-entertainment company. Its published story describes a game-login traffic scenario where Kubernetes and HPA supplied elastic capacity and load tests validated service behaviour.

Elastic scaling required performance evidence

Adding container replicas does not always increase throughput linearly; the constraint may be compute, a shared dependency, or application code.

Load-test throughput reached a plateau after scaling

The published test showed limited additional throughput as Pods were added, which resource counts alone could not explain.

Implementation

Analyse the load test with APM, logs, and profiling

The team deployed DataKit in the container environment, ingested traces and logs, reviewed suspect services and Redis in APM, then used profiling signals including Lock Wait Time and Socket I/O Read Time to locate a code path making frequent Redis calls.

What changed

The code bottleneck gained reproducible evidence

Developers changed the implementation using trace, Redis, and profile evidence and repeated the load test with the same resources, validating improved throughput for that scenario; it is not a result guarantee for other workloads.