服务器性能和可伸缩性杀手（转1）

现在，服务器性能问题是许多书写桌面应用程序的人所要面对的问题。组件对象模型（Component Object Model，COM）和Component ware的成功产生了一个意想不到的结果，这就是如果使用像ASP（IIS的一个扩展）这样的应用程序服务器，就不用编写主机代码了，其实以前的主机代码都不是在真正的服务器环境下编写的。桌面环境和服务器环境之间有许多重要的不同，这些不同会在性能上产生不可预测的影响。

桌面应用程序服务器

影响桌面应用程序性能的因素是众所周知的。长指令路径意味着更慢的代码，这是性能方面的一个主要缺陷。使用大量资源会使应用程序变得更加臃肿，这样系统中的其他应用程序可用的资源就会更少。减慢启动时间会激怒用户。太多的运行设置会使机器的页错误率增高，使它们变慢而且反映迟钝。服务器应用程序也常受到这些因素影响，另外还有一些其他因素介绍如下：

通常，服务器应用程序同时处理的客户没有几百也有几十。对桌面应用程序来说，如果能在1/10秒内对用户做出反应就算是很快的了。假设一个操作需要整整100ms的话，那么这个应用程序在一秒中只能进行10个操作。大多数服务器应用程序需要比每秒钟十次请求大得多的通量。高延迟时间网络（延迟时间=消息的传输时间）加长了反应时间，这就需要服务器的反应更快以满足要求。

服务器应用程序经常处理大量的数据设置。效率低下的，尤其是那些浪费运行时间的方法，是不能用于处理上百万条数据的。

服务器机器比桌面机器更强大。服务器机器有更多的内存，更大的磁盘，更快的CPUs，并且通常有多个处理器。但是这些仍然不够。桌面机器处理的是零星的突发性业务，大部分时间是空闲的，而服务器的负载是连续不断的。服务器机器很昂贵，必须运行得很好才行。

服务器应用程序需要具有以月计算的正常运行时间。过了一段时间后，服务器的性能必须不会由于资源泄露或 cruft（一种需要周期性清除的数据结构和统计结果）的积聚而降低。

大多数服务器应用程序都需要采用多线程结构。考虑一个一次只处理一个请求。而将大部分时间都化在I/O上的单线程服务器，这样的性能是很难让人接受的。线程池可以利用其他空闲的处理器时钟周期同时处理几个请求。为了充分利用多处理器系统，服务器应用程序必须是多线程的。不幸的是，多线程应用程序很难编写，很难调试，而且很难运行得好，尤其是在多处理器系统中。但是一旦正确地得到它，其性能会远远超过同样的单线程应用程序，从这一点来说，使用多线程应用程序还是值得的。

单线程应用程序相对简单，很容易理解：程序中某一时刻只有一个事件发生。在多
线程应用程序中，并发行为导致复杂的相互作用，其影响很难预测。另外，这些相
互作用，不管是否是灾难性的，都很难再生。桌面应用程序很少有多于一个线程
的，即使有，这些线程也只是用于分立的后台业务，例如打印。


IIS的灵活性和性能

Inte.net Information Server（IIS）是一个应用程序服务器。在很多方面，它像是一个虚拟操作系统，因为有许多ASP和ISAPI应用程序在处理间隔中运行。

IIS使用一个I/O线程池来处理所有到来的请求。对静态文件（.htm，.jpg等文件）的请求会马上得到满足，而对动态内容的请求被分派到适当的ISAPI扩展动态连接库。ASP扩展利用一个工人线程池运行ASP页。因为ASP是基于COM的，所以所有组件都是在我们的处理过程中执行的。这是一个好坏掺半的事情。它对开发者来说是好极了，因为它允许组件的简单重用，使ASP非常灵活，因此使ASP和IIS非常成功。但是，这个灵活性导致了性能问题。因为许多组件是为桌面系统编写的，并且许多专门为ASP创建的组件是由那些不是十分会写高性能服务器组件的人编写的。

对ISAPI扩展和过滤器也是一样。不同组件之间及同一组件的不同实例中都存在着严重的相互影响。

下面的所有说明都适用于IIS，其中的大多数也适用于其他服务器应用程序。

原文转自：http://www.ltesting.net