对性能和可扩展性之间关系的误解

性能和可扩展性是不同的，但是两者又不是完全不一致的。例如，当100个用户传输信息的时候，一个应用软件可以以难以想象的速度来处理信息。当应用程序到达10，000个用户在同时提供输入那一刻时，性能可能急剧降低，因为在开发循环期间的一系列考虑中可伸缩性还不是足够高。另一方面，同样高性能的应用软件可能是在后面的反复过程中被部分地复写，而且可以同时毫无问题的处理100，000个消费者。可是，到了那时候，一定数量的消费者可能已经转移到其他一些人首次使用良好的产品中了。

有时应用软件根据用并发用户数目衡量的性能来追求可扩展性，依据该想法，提高应用程序的运行速度，可以使单一服务器支持更多的用户。这个方案产生的问题是渐增的大量并发用户可能产生一个瓶颈，这个瓶颈随着负载的增长而降低了性能水平。这种行为的一个原因就是高速缓存的状态和中间层的数据。通过在开发进程的设计阶段避免这样的高速缓存状态，可以节省返回和重编码的大量时间。这个理想状态就是寻找一个平衡点，它在一个特殊的应用软件的可伸缩性的实现过程中提供了可以接受的性能。找到的这个点总是需要进行折衷处理。

让我们看一下一些有关可扩展性的基本概念。就像Frank E. Redmond III在MSDN文章“设计和构建windows DNA应用软件入门”中指出的那样，吞吐量涉及一个应用软件在标准时间内能执行的工作量（处理量），而且经常是通过每秒的处理量（tps）来计算。可伸缩性涉及当资源增加或减少时发生的线性吞吐量的变化量。那就是允许一个应用软件在任何地方支持少数用户到成千上万的用户，并且通过简单的增加和减少的资源去“定制大小”此应用软件。最后，处理时间涉及获得必须资源所需的时间总量，加上运用这些资源的处理过程实际上所花费的时间总量。

这里提到的观点是可扩展性是随着吞吐量的增加而增加的;也就是说，每部分资源吞吐量的增长越高，可伸缩性就越大。显然，如果应用软件的开发者们想增加可伸缩性的话，那么他们必须集中全力增加吞吐量地增长，当然，那么显然的问题就产生了，怎样正确的着手去增加吞吐量呢？对于这个问题的答案听起来可能很简单：减少处理时间的总量。但是可能是那么简单吗？

处理时间可以通过多种因素来扩展。获得必须的资源可能被诸如网络反应时间、磁盘存取速度、数据库锁定配置和资源抢夺因素而减慢。还有更多的因素影响资源使用时间，例如网络反应时间、用户输入和绝对工作量。Windows DNA 应用软件开发者应该全力尽可能地降低保持资源的获得和资源的利用次数。Frank Redmond列出以下办法来控制这些因素：

• 避免使用户的交互作用成为一个处理的一部分。
• 避免网络交互作用成为一个处理的一部分。
• 晚获得资源并且早释放它们。
• 使更多的资源可用。否则，用MTSM去共享那些短期储存或者花费很多才能建立的资源。