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