在系统基准测试中，延迟（完成单个请求所需的时间）与吞吐量（每秒处理的请求数量）之间通常存在权衡。当系统处理低查询量（QPS）负载时，由于 CPU、内存或网络带宽等资源未完全饱和，它可以优先考虑快速响应。例如，一个 Web 服务器通过为每个请求分配充足资源，可能以 100ms 的延迟处理每秒 50 个请求。但当 QPS 增加（例如达到每秒 200 个请求）时，同一系统的延迟可能会上升到 500ms。发生这种情况是因为传入请求开始竞争有限的资源，导致队列延迟、上下文切换或共享组件（如数据库或缓存）出现瓶颈。这种关系不是线性的：延迟可能在达到一个关键 QPS 阈值之前保持在可控范围内，之后迅速恶化。
影响这种权衡的因素有几个。硬件限制（例如，CPU 核数、内存带宽）对吞吐量设定了硬性上限，而软件设计选择（如并发模型：线程池 vs 事件循环）决定了资源的使用效率。例如，使用固定大小线程池的系统可能在低 QPS 下实现低延迟，但在高负载下，线程会因等待 I/O 而阻塞，导致请求堆积。相反，异步事件驱动架构（如 Node.js）可能通过避免线程竞争来维持更高的吞吐量并使延迟逐步增加。另一个例子是缓冲或批量处理：数据库可能会缓冲写入操作以进行批量处理，从而提高吞吐量，但由于单个写入操作需要等待分组处理而增加了延迟。这种权衡取决于系统是优先考虑每个请求的速度（延迟）还是整体容量（吞吐量）。
选择正确的平衡点取决于应用程序的需求。实时系统（例如，游戏、交易平台）优先考虑低延迟，即使这意味着限制吞吐量，因为延迟响应是不可接受的。批量处理系统（例如，数据管道）侧重于最大化吞吐量，接受更高的延迟以高效处理大量数据。为了进行优化，开发人员可以在实际负载下测试系统以识别瓶颈（例如数据库连接池达到上限），并调整配置（例如增加连接池大小）或通过增加服务器来横向扩展。监控工具可以跟踪第 95 百分位延迟等指标，以便尽早发现性能下降。例如，一个电商网站可能会在流量高峰期自动扩容服务器，以保持延迟低于 200ms，即使单台服务器的吞吐量略有下降。关键在于根据工作负载的具体需求调整设计和基础设施，而不是追求理论上的最大值。