日期:2008-09-11  浏览次数:21517 次

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


桌面应用程序服务器

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

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

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

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

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

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

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


IIS的灵活性和性能

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

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

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

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