不要进行丈量

当你能够丈量你所表达的事情并用数字表达它时，这就表示你对他有了一定的了解；可是假如你不能用数字表达时，你的知识是贫瘠的不能令人满意的；这可能是知识的开始，但这时你简直不会将你的思想提高到科学的水平。
- Lord Kelvin (William Thomson)

假如不丈量你就不能了解应用程序的特性。你在黑暗中摸索，一半是靠猜想。假如不识别性能问题，你就不能做任何改进或做出工作量计划。

丈量包含黑匣子丈量和profiling。黑匣子丈量的意思是收集由性能计数器（内存使用，上下文交换，CPU利用等）和外部检测工具（通量，反映时间等）所显示的数据。为了profile你的代码，你编译代码的一个工具版，然后在各种条件下运行它，并收集关于执行时间和过程调用频率的统计数据。

丈量假如不用于分析的话就一点用都没有。丈量将不仅告诉你有问题，而且甚至能帮助你找到问题发生在哪，但它不能告诉你为啥会有问题。对问题进行研究分析以便你能正确地改正他们。要从根本上处理问题而不是停留在表面现象。

当你进行改动后，要重新丈量。你要知道你的改动是否有效。改动也有可能会袒露其它性能问题，丈量-分析-改正-再丈量的循环就会重新开始。你也务必要有规律地进行丈量，以便发现性能衰退问题。

应该使用单一用户，单一请求的测试方法。

书写ASP和ISAPI应用程序的一个通病是只用一个浏览器去测试应用程序。当他们在Internet上应用他们的程序时，他们才发现他们的应用程序不能处理高负载，并且通量和反应时间另人可怜。

用一个浏览器测试是必要的可是不够的。如果浏览器反应得不够快，你就知道你有麻烦了。但即便它在使用一个浏览器时很快，你也不清楚它处理负载的能力如何。如果十几个用户同时请求会发生啥事？一百个呢？你的应用程序能容忍啥样的通量？它能提供啥样的反应时间？在轻载时这些数字会怎样？中等负载呢？重载呢？在多处理器机器上你的应用程序会如何？对你的应用程序进行强度测试，这对于找出bugs发现性能问题来说是基本的。

类似的负载测试考虑适用于所有的服务器应用程序。

不应使用实际环境。

人们往往只在几个特定的，人工的环境（如下benchmarks）下调整应用程序。选择和实际情况相对应的各种情况，并为针对各种操作进行优化，这一点很关键。假如你不这样做，你的用户和评论家一定会这样做，并且他们将依此来评判你的应用程序的好坏。
结论

自从我们开始开发IIS以来，我们已经对抹杀服务器性能和伸缩性有了一定的了解。书写高性能的服务器应用程序是不简单的。除了在书写桌面应用程序时遇到的传统问题外，你务必特别注意内存分配，缓存列，缓存数据，线程原型化，加锁策略，多处理器机器，模块化调用，丈量和分析，多用户测试，和实际环境的问题。这些问题可能会造就你也有可能毁了你。