· 假如您不能得到锁，使用TryEnterCriticalSection并做一些其他的有用的工作。
高竞争导致serialization，serialization导致降低CPU的利用率，这促使用户加入更多的线程，结果事情变得更糟。
6.不必注意多处理器机器
您的代码在多处理器系统上比在单处理器系统上运行得还要糟，这可能是件令人恶心的事。一个很自然的想法是，在一个N维系统上运行N次会更好。性能很差的原因是竞争：锁竞争，总线竞争，和/或缓存列竞争。处理器都在是争夺共享资源的任何权，而不是做更多的工作。
假如您一定要编写多线程应用程式的话，您应该在多处理器盒上对您的应用程式进行强度测试和性能测试。单处理器系统通过时间分片地执行线程而提供一个并发性的假象。多处理器盒具备真正的并发性，竞争环境和竞争更容易发生。
7.应该始终使用模块化调用；他们很有趣。
利用同步模块化调用来执行I/O操作对大多数桌面应用程式来说是合适的。但是，他们不是使用服务器上的CPU（s）的好方法。I/O操作要花费上百万个时钟周期来完成，这些时钟周期本来能够被更好地利用。利用异步I/O您能得到显著提高的用户请求率和I/O通量，但是增加了额外的复杂性。
假如您有需要花费很长时间的模块化调用或I/O操作，您应该考调拨多少资源给他们。您想使用任何的线程还是有个限制？一般地，使用有限的几个线程要好些。构建一个小的线程池和队列，利用队列来安排线程的工作完成模块化调用。这样，其他线程就能够拾取和处理您的非模块化的请求。
8.不要进行测量
当您能够测量您所谈论的事情并用数字表达他时，这就表示您对他有了一定的了解；但是假如您不能用数字表达时，您的知识是贫瘠的不能令人满意的；这可能是知识的开始，但这时您简直不可能将您的思想提高到科学的水平。
- Lord Kelvin (William Thomson)
假如不测量您就不能了解应用程式的特性。您在黑暗中摸索，一半是靠猜测。假如不识别性能问题，您就不能做任何改进或做出工作量计划。
测量包括黑匣子测量和profiling。黑匣子测量的意思是收集由性能计数器（内存使用，上下文交换，CPU利用等）和外部检测工具（通量，反映时间等）所显示的数据。为了profile您的代码，您编译代码的一个工具版，然后在各种条件下运行他，并收集关于执行时间和过程调用频率的统计数据。
测量假如不用于分析的话就一点用都没有。测量将不但告诉您有问题，而且甚至能帮助您找到问题发生在哪，但他不能告诉您为什么会有问题。对问题进行分析以便您能正确地改正他们。要从根本上解决问题而不是停留在表面现象。
当您进行改变后，要重新测量。您要知道您的改变是否有效。改变也可能会暴露其他性能问题，测量-分析-改正-再测量的循环就会重新开始。您也必须要有规律地进行测量，以便发现性能衰退问题。
9.应该使用单一用户，单一请求的测试方法。
书写ASP和ISAPI应用程式的一个通病是只用一个浏览器去测试应用程式。当他们在Internet上应用他们的程式时，他们才发现他们的应用程式不能处理高负载，并且通量和反应时间另人可怜。
用一个浏览器测试是必要的但是不够的。假如浏览器反应得不够快，您就知道您有麻烦了。但即使他在使用一个浏览器时很快，您也不知道他处理负载的能力如何。假如十几个用户同时请求会发生什么事？一百个呢？您的应用程式能容忍什么样的通量？他能提供什么样的反应时间？在轻载时这些数字会怎样？中等负载呢？重载呢？在多处理器机器上您的应用程式会如何？对您的应用程式进行强度测试，这对于找出bugs发现性能问题来说是基本的。
类似的负载测试考虑适用于任何的服务器应用程式。
10.不应使用实际环境。
人们往往只在几个特定的，人工的环境（如下benchmarks）下调整应用程式。选择和实际情况相对应的各种情况，并为针对各种操作进行优化，这一点很重要。假如您不这样做，您的用户和评论家一定会这样做，并且他们将依此来评判您的应用程式的好坏。
