Python 高手编程系列二百九十：分析网络使用情况

正如我前面所说，与第三方程序（如数据库、缓存、Web 服务或 LDAP 服务器）通信的应用程序可能会在这些应用程序运行缓慢时放慢速度。在应用程序端使用常规代码分析
方法可以进行跟踪。但是，如果第三方软件自己工作正常，那么罪魁祸首可能是网络。
问题可能是配置错误的集线器，低带宽网络链路，或甚至是大量的使计算机多次发送
相同的数据包的流量冲突。
这里有几个元素，你应该收集一下。要了解发生了什么，首先要研究以下 3 个领域：
• 使用以下工具观察网络流量。
○ ntop：http://www.ntop.org（仅限 Linux）。
○ wireshark：www.wireshark.org（以前命名为 Ethereal）。
• 使用 net-snmp 跟踪不正常或错误配置的设备（http://www.net-snmp.org）。
• 使用统计工具 Pathrate 来估量两台计算机之间的带宽。参见 http://www.cc.gatech.
edu/～dovrolis/bw-est/pathrate.html。
如果你想进一步了解网络性能问题，你可能还需要阅读 Richard Blum 的 Network
Performance Open Source Toolkit。本书公开了调整大量使用网络的应用程序的策略，并提供
了一个扫描复杂网络问题的教程。
Jeremy Zawodny 所著的 High Preformance MySQL 也是一本很好的书，在编写使用 MySQL
的应用程序时值得一读。
小结
在本章中，我们已经看到。
• 3 个优化规则如下。
○ 首先要能工作。
○ 从用户的角度考虑。
○ 保持代码的可读性。
• 基于编写具有速度目标场景的优化策略。
• 如何分析 CPU 或内存使用情况和一些网络分析提示。
现在，你已经知道如何找到性能问题，下一章将介绍一些常见的解决性能问题的通用策略。‘
优化——一些强大的技术
优化程序不是一个神奇的过程。遵循一个简单的算法就可以完成，这个算法由 Stefan
Schwarzer 在 Europython 2006 上综合给出，他的原始伪代码示例如下：
def optimize():
“”“推荐的优化过程”“”
assert got_architecture_right(), “fix architecture”
assert made_code_work(bugs=None), “fix bugs”
while code_is_too_slow():
wbn = find_worst_bottleneck(just_guess=False,
profile=True)
is_faster = try_to_optimize(wbn,
run_unit_tests=True,
new_bugs=None)
if not is_faster:
undo_last_code_change()

By Stefan Schwarzer, Europython 2006

这个例子可能不是最整洁，最清晰的，但是它几乎抓住了一个有组织的优化过程的所
有的重要方面。从中我们可以学到的主要内容如下。
• 优化是一个迭代过程，在这个过程中，并不是每次迭代都会有更好的结果。
• 主要先决条件是通过测试验证并且正常工作的代码。
• 你应该始终专注于优化当前的应用程序的瓶颈。
让你的代码工作地更快不是一个容易的任务。如果是抽象的数学问题，解决方案当然在
于选择正确的算法和适当的数据结构。但在这种情况下，很难提供一些通用的提示和技巧，
可以在任何代码中用于解决算法问题。当然有一些通用的方法来设计一个新的算法，甚至是
可以应用于各种各样的问题的元启发式算法，但它们是语言无关的，因此不在本书的范围。
总之，一些性能问题只是由某些有质量缺陷的代码或应用程序的使用上下文引起的。
例如，以下问题可能会降低应用程序的运行速度。
• 基本内置类型的使用不当。
• 太复杂。
• 硬件资源使用模式与执行环境不匹配。
• 过于长时间的等待来自第三方 API 或后台服务的响应。
• 在应用程序的时间关键部分做太多。
更常见的是，解决这样的性能问题不需要高级的学术知识，只要有良好的软件技能即
可。技能的关键在于知道何时使用合适的工具进行处理。幸运的是，已经有一些著名的模
式和解决方案来处理性能问题。
在本章中，我们将讨论一些常用的和可重用的解决方案，你可以通过以下非算法方法
优化你的程序。
• 降低复杂度。
• 架构体系的权衡。
• 缓存。正如我前面所说，与第三方程序（如数据库、缓存、Web 服务或 LDAP 服务器）通信的应用程序可能会在这些应用程序运行缓慢时放慢速度。在应用程序端使用常规代码分析
方法可以进行跟踪。但是，如果第三方软件自己工作正常，那么罪魁祸首可能是网络。
问题可能是配置错误的集线器，低带宽网络链路，或甚至是大量的使计算机多次发送
相同的数据包的流量冲突。
这里有几个元素，你应该收集一下。要了解发生了什么，首先要研究以下 3 个领域：
• 使用以下工具观察网络流量。
○ ntop：http://www.ntop.org（仅限 Linux）。
○ wireshark：www.wireshark.org（以前命名为 Ethereal）。
• 使用 net-snmp 跟踪不正常或错误配置的设备（http://www.net-snmp.org）。
• 使用统计工具 Pathrate 来估量两台计算机之间的带宽。参见 http://www.cc.gatech.
edu/～dovrolis/bw-est/pathrate.html。
如果你想进一步了解网络性能问题，你可能还需要阅读 Richard Blum 的 Network
Performance Open Source Toolkit。本书公开了调整大量使用网络的应用程序的策略，并提供
了一个扫描复杂网络问题的教程。
Jeremy Zawodny 所著的 High Preformance MySQL 也是一本很好的书，在编写使用 MySQL
的应用程序时值得一读。
小结
在本章中，我们已经看到。
• 3 个优化规则如下。
○ 首先要能工作。
○ 从用户的角度考虑。
○ 保持代码的可读性。
• 基于编写具有速度目标场景的优化策略。
• 如何分析 CPU 或内存使用情况和一些网络分析提示。
现在，你已经知道如何找到性能问题，下一章将介绍一些常见的解决性能问题的通用策略。‘
优化——一些强大的技术
优化程序不是一个神奇的过程。遵循一个简单的算法就可以完成，这个算法由 Stefan
Schwarzer 在 Europython 2006 上综合给出，他的原始伪代码示例如下：
def optimize():
“”“推荐的优化过程”“”
assert got_architecture_right(), “fix architecture”
assert made_code_work(bugs=None), “fix bugs”
while code_is_too_slow():
wbn = find_worst_bottleneck(just_guess=False,
profile=True)
is_faster = try_to_optimize(wbn,
run_unit_tests=True,
new_bugs=None)
if not is_faster:
undo_last_code_change()

By Stefan Schwarzer, Europython 2006

这个例子可能不是最整洁，最清晰的，但是它几乎抓住了一个有组织的优化过程的所
有的重要方面。从中我们可以学到的主要内容如下。
• 优化是一个迭代过程，在这个过程中，并不是每次迭代都会有更好的结果。
• 主要先决条件是通过测试验证并且正常工作的代码。
• 你应该始终专注于优化当前的应用程序的瓶颈。
让你的代码工作地更快不是一个容易的任务。如果是抽象的数学问题，解决方案当然在
于选择正确的算法和适当的数据结构。但在这种情况下，很难提供一些通用的提示和技巧，
可以在任何代码中用于解决算法问题。当然有一些通用的方法来设计一个新的算法，甚至是
可以应用于各种各样的问题的元启发式算法，但它们是语言无关的，因此不在本书的范围。
总之，一些性能问题只是由某些有质量缺陷的代码或应用程序的使用上下文引起的。
例如，以下问题可能会降低应用程序的运行速度。
• 基本内置类型的使用不当。
• 太复杂。
• 硬件资源使用模式与执行环境不匹配。
• 过于长时间的等待来自第三方 API 或后台服务的响应。
• 在应用程序的时间关键部分做太多。
更常见的是，解决这样的性能问题不需要高级的学术知识，只要有良好的软件技能即
可。技能的关键在于知道何时使用合适的工具进行处理。幸运的是，已经有一些著名的模
式和解决方案来处理性能问题。
在本章中，我们将讨论一些常用的和可重用的解决方案，你可以通过以下非算法方法
优化你的程序。
• 降低复杂度。
• 架构体系的权衡。
• 缓存。