本主题介绍有关如何调查瓶颈的建议过程。
问题的来源是什么？
问题的根源可能与硬件或软件相关。 当资源使用不足时，它通常表示系统中某个位置存在瓶颈。 瓶颈可能是由于硬件限制或由于软件配置效率低下或两者都会导致。
识别瓶颈是一个增量过程，通过它缓解一个瓶颈可能会导致发现下一个瓶颈。 识别和缓解这些瓶颈的科学是本主题的目标。 系统可以在短时间内在高峰时段内执行。 但是，对于可持续的吞吐量，系统的处理速度只能与表现最慢的组件一样快。
使用串行方法
系统终结点（入口/退出）或中间某个位置（业务流程/数据库）可能会出现瓶颈。 在瓶颈的位置被隔离后，可以采用结构化方法来识别源。 在缓解瓶颈后，必须再次测量性能，以确保系统中的其他位置没有进一步引入新的瓶颈。
应以串行方式确定和修复瓶颈的过程，其中一次只应改变一个参数，然后测量性能以验证该单个更改的影响。 一次更改多个参数可能会隐藏更改的效果。
例如，更改参数 1 可以提高性能，但是，将参数 2 与更改参数 1 结合使用可能会产生不利影响，从而否定更改参数 1 的好处，从而导致净零效果。 但是，这会导致对不同参数 1 的效果出现假阴性，对不同参数 2 的效果出现假阳性。
测试一致性
更改设置后测量性能特征是验证更改效果的必要条件。
硬件：使用一致的硬件非常重要，因为不同的硬件可能会显示不一致的行为，从而产生误导性的结果，例如不使用笔记本电脑。
测试运行持续时间：在固定的最小时间段内测量性能也很重要，以确保结果确实可持续，而不仅仅是峰值。 运行较长时间的测试的另一个原因是，确保系统经过所有缓存被填充的初始暖/加速期，数据库表中的数据量达到预期，限流在达到预定义阈值后有足够的时间启动并调节吞吐量。 此方法有助于发现最佳的可持续吞吐量。
测试参数：测试运行与测试运行之间也不必改变测试参数。 例如，不同的地图复杂性和/或文档大小可能会产生不同的吞吐量和延迟结果。
清理状态：测试完成后，在运行下一次测试运行之前，必须清除所有状态。 例如，历史数据可以在影响运行时吞吐量的数据库中生成。 回收服务实例有助于释放缓存的资源，例如内存、数据库连接和线程。
预期：吞吐量与延迟
从部署的系统预期会有一定数量的吞吐量和/或延迟是合理的。 尝试同时实现高吞吐量和低延迟就像往两个不同的方向拉。 可以合理地期待最佳吞吐量和合理的延迟。 随着吞吐量的提高，增加的压力（例如：CPU 消耗量增高、磁盘 IO 争用激烈、内存压力增大、锁争用加剧）作用于系统，从而可能对延迟产生负面影响。 若要发现系统的最佳容量，必须识别和缓解任何和所有瓶颈。
瓶颈可能是由于驻留在数据库中的旧数据（已完成实例）未清除造成的。发生这种情况时，性能可能会降低。 给系统足够的时间排水可以帮助缓解问题。 但是，发现积压工作积累的原因和帮助缓解问题非常重要。
若要发现积压工作的原因，必须分析历史数据、监视性能监视器计数器（发现使用模式和诊断积压工作的来源）。 这是一种常见情况，即在夜间以批量方式处理大量数据。 了解系统的容量以及其从积压中恢复的能力，对估算处理超速情况下的硬件需求和系统中所需的缓冲空间以应对意料之外的吞吐量峰值非常有帮助。
优化系统以实现最佳可持续吞吐量需要深入了解要部署的应用程序、系统的优势和弱点以及特定方案的使用模式。 唯一的方式是通过对与将会用于生产的拓扑进行彻底测试，从而发现瓶颈以及预测最优可持续吞吐量并具有一定确定性。
本部分中的其他主题将指导你如何定义该拓扑，并提供如何缓解瓶颈的指导，希望能够首先避免出现瓶颈。
规模化
在部署的拓扑的各个阶段可能会出现瓶颈。 升级硬件可以解决一些瓶颈。 可以通过纵向扩展（更多 CPU、内存或缓存）或横向扩展（其他服务器）来升级硬件。 纵向扩展/横向扩展的决定取决于遇到的瓶颈类型和正在配置的应用程序。 下面将帮助你了解如何根据遇到的瓶颈更改硬件部署拓扑。 应用程序需要从头开始构建，才能利用纵向扩展/横向扩展。例如：
如果应用程序被序列化并依赖于单个执行线程，那么即使使用额外的 CPU 和/或内存来纵向扩展服务器，也可能不会有助于缓解问题。
如果额外的服务器只是为无法扩展的资源增加了争用，那么通过增加服务器来扩展系统可能不会有帮助。 但是，横向扩展可提供其他优势。 部署两个双处理器服务器而不是一个四处理器服务器可以提供一个冗余服务器，这个服务器有两个目的：一是用于扩展以处理额外的吞吐量，二是提供高度可用的拓扑结构。