Go service performance depends on the workload, data size, dependencies and hardware. QPS and latency figures are meaningful only with a reproducible test description. This planning guide explains what to measure and how to review an optimization proposal; it does not promise a throughput or response time.
Define the workload before the target
| Input | Record in the test plan | Why it matters |
|---|---|---|
| Traffic | Request mix, concurrent users, bursts and test duration | A single cached endpoint does not represent the product |
| Data | Dataset size, query shape and cache state | Small or warm datasets can hide database limits |
| Environment | CPU, memory, network and external dependencies | Results cannot be transferred between environments unchanged |
| Outcome | Percentile latency, error rate, throughput and resource use | Average latency hides slow requests and failures |
Measure the bottleneck
Use profiling to examine CPU, allocations and blocking, and traces to follow time spent across a request. Database connection waits, slow queries and external APIs can dominate even when application CPU is low. Profiling has overhead, so document its use and compare under consistent conditions. See the official Go diagnostics guide.
Apply one change against the baseline
Possible changes include query indexing, bounded concurrency, context deadlines, connection-pool tuning or caching. State the expected mechanism, invalidation rules and failure behavior. Compare each change with the baseline using the same workload; retain a change only when the intended behavior and performance improve together.
Request a backend performance review
Prepare affected endpoints, observed traffic, latency and error samples, database size, hosting limits and any prior test method. Remove credentials and personal data from traces. Explore backend and business system development or send a performance review brief. Agree measurable acceptance and a rollback plan before implementation.