使用IIS 5.0调整Web服务器的艺术与科学

小鬼

安全性

　　在性能与用户关心的Web服务器安全性之间找出平衡点是您将面对的重要问题之一，尤其是当您经营电子商务网站更是如此。因为安全的网络通讯比不安全的网络通讯需要更多资源，所以知道何时应使用不同的安全技术 (如 SSL 通讯协议或 IP 地址检查)，以及何时不该使用它们是很重要的。例如，您的首页或一个搜寻结果页几乎不需要通过 SSL 执行。但是，当用户进入一个结帐或采购网页时，您就需要确定该页是安全的。

　　如果使用 SSL，则请注意，建立初始连接比重新连接已经在 SSL 有效期缓存中的安全信息的成本要高上五倍。SSL 有效期缓存的默认超时时间，已经从 Windows NT 4.0 中的 2 分钟改变为在 Windows 2000 中的 5分钟。一旦这个资料被清除时，客户端及服务器就必须建立一条全新的连接。如果打算支持长时间的 SSL 有效期，则可利用 ServerCacheTime 注册表设置来延长这个超时时间。如果预计会有几千位用户使用 SSL 连接到您的站点，则较安全的方式是预估需要 SSL 有效期持续的时间，然后将 ServerCacheTime 参数设成比您预估的时间稍长一些。请勿将超时时间设置值超过此参数，否则您的服务器会在缓存中留下旧的资料。此外， 请确定 HTTP Keep-Alives 已启用。除非浏览器明确地关闭连接，否则 SSL 有效期与 HTTP Keep-Alives 并用时不会超时。

　　除了具备高性价比的所有安全性技术外，Windows 2000 及 IIS 5.0 安全性服务也整合到一些操作系统服务中。这表示您无法从这些服务的其它领域个别监视安全性性能。反之，测量安全性是否消耗系统资源最常用的方式是执行测试，分别比较有安全性功能及没有安全性功能时的服务器性能有何不同。此测试在进行时必须使用固定的工作量及固定的服务器设置，让安全性功能成为唯一的变量。在测试期间，您可能需要测量下列项目︰
　　
　　·    处理器活动及处理器队列︰验证、IP 地址、检查、SSL 通讯协议，及加密安全性是需要特别处理的安全性功能。您可能会在专用模式或用户模式中看见增加的处理器活动，以及内容切换与中断的比率增加。如果服务器中的处理器不足，无法处理增加的负载，便可能形成队列。密码加速器之类的硬件在这里可能会有所帮助。

　　·    如果正在使用 SSL 通讯协议，则 lsass.exe 可能会耗用惊人的 CPU 容量。这是因为 SSL 进程是在这里进行。这表示习惯在 Windows NT 中监视 CPU 使用情况的管理员会看见 Inetinfo.exe耗用较少的处理器，但 Isass.exe 却耗用很多。

　　·    使用的物理内存︰安全性需要系统存放及获取更多用户信息。此外，SSL 通讯协议可以使用长识别码-40 位到 1,024 位-来加密及解密信息。

　　·    网络传输量：您也可能会在 IIS 5.0 的服务器，及用来验证登入密码并验证 IP 地址的域控制站之间，看见增加的传输量。

　　·    等待时间及延迟︰复杂的安全性特性 (如 SSL) 导致最明显的性能降级就是花在加密及解密的时间和精力，因为这两者会使用大量的处理器循环。从使用 SSL 通讯协议的服务器上下载文件比不使用 SSL 的服务器下载文件会慢上10 到 100 倍。

　　如果服务器不仅用来执行 IIS 5.0，还作为域控制站使用，则域服务所耗用的处理器用量、内存、网络及磁盘活动的比例可能会因为这些资源上而带来明显的增加。增加的活动足以让 IIS 5.0 服务无法有效地执行。强烈建议您避免在域控制站上执行 IIS 5.0。

　　监视网络应用程序

　　使用一个设计完善且已彻底测试过的应用程序来升级或替换一个撰写不佳的应用程序，可以显著地增强性能 (有时可增加到三倍)。不过，请记住您的网络应用程序可能会受到后端等待时间的影响 (例如 A4/400 等较传统系统)。远程资料来源会引起性能问题的原因很多。如果开发人员将应用程序设计成从另一个网站上取得资料，但目标网站却出现当机，则该应用程序会在您的服务器上造成瓶颈。如果应用程序正在存取远程 SQL 服务器的数据库，则该数据库可能无法跟上传送给它的请求。因为您可能是自己站点的 SQL 数据库管理员，所以要监视这些位于远程的服务器可能会有困难。更糟的是，您可能没有这些数据库服务器或其它后端服务器的控制权。如果可以的话，请监视与您的应用程序一起使用的后端服务器，并将它们调整得与您的Web服务器一样的好。

　　若要判定您的 Web 服务器是否正在您的服务器上造成瓶颈，请监视下列性能计数器︰

　　·    Active Server Pages︰Requests/Sec、Active Server Pages︰Requests Executing、Active Server Pages︰Request Wait Time、Active Server Pages︰Request Executing Time 及 Active Server Pages︰Requests Queued。如果正在服务器上执行 ASP 应用程序，则这些计数器可让您了解这些应用程序执行的状况有多好。「Active Server Pages︰Requests/Sec」不含静态文件或其它动态内容的请求，它会根据 ASP 网页的复杂度及您 Web 服务器的容量明显地变动。如果这个计数器在服务器上的传输量处于尖峰期间出现低值的话，则您的应用程序可能会导致瓶颈。「Requests Executing」显示目前正在执行的请求数目；「Request Wait Time」显示最近的请求在队列中等待的毫秒数；「Request Execution Time」显示最近的请求花在执行上的毫秒数。理想的状态是「Requests Queued 」及「Request Wait Time」应保持接近 0，但它们会在不同的载量下起伏变动。最大「Requests Queued」数目是由 AspRequestQueueMax 的 Metabase 设置来决定。如果达到此限制，则客户端浏览器将显示 [HTTP 500/ 服务器太过忙碌]。如果这些数字大幅偏离了预计的范围，则您的 ASP 应用程序可能必须重写才能提高性能。由于「Request Execution Time」并非一个平均值，所以会有些误差。例如，如果您固定会接收一页 30 个请求，每页是以 10 毫秒到 500 毫秒的速度执行每一个请求，则即使平均执行时间超过 25 毫秒，但是计数器可能会显示 10 毫秒。要为「Requests Executing」说出一个最适当的值很难。如果页面执行得很快，而且不会等待 I/O (加载文件或提出数据库查询)，则这个数字可能会比较低 (比机器忙碌时的处理器个数低一些)。如果页面必须等待 I/O，则执行的页数可能会较高 (接近 AspProcessorThreadMax 乘以处理器个数的值)。如果「Requests Executing」的值是高的、「Requests Queued」是大的，而 CPU 的使用率是较低的，则可能必须增加 AspProcessorThreadMax。启用时，传送的线程会试着最佳化「Requests Executing」。用户的响应时间会与「Request Wait Time」加「Request Execution Time」加网络等待时间的和成比例。

　　·    Web Service: CGI Requests/sec及 Web Servcie: ISAPI Extension Requests/Sec 会报告您的服务器是以哪个速度处理 CGI 及 ISAPI 应用程序请求。如果这些值在负载增加时降低，则可能必须请求应用程序开发人员重新检查他们的程序代码。
附注-ASP 是个「ISAPI Extension」，包含在第二个计数器中。

　　·    Web Service: Get Requests/sec及Web Service: Post Requests/Sec 反应这两个常见 HTTP请求类型是以哪个速度出现在您的服务器上。「Post Request」通常是用于窗体，并传送到 ISAPI (包括 ASP) 或 CGI。「Get Request」会记录几乎所有来自浏览器的其它请求，并包括静态文件、APS 与其它 ISAPI 的请求，以及 CGI 请求。

调整 Web 应用程序

　　IIS 5.0 对于服务静态 HTML 网页及配上默认的设置值基本就已足够了。如果您的站点主要是静态内容，则许多性能问题可能会与硬件有关。IIS 5.0 为 Web 应用程序提供不错的性能，但若想获得最佳的性能，还需要一些额外的调整。当然，不管服务器软件如何增强，与 Web 应用程序设计及程序代码有关的最佳经验方法的问题依然会存在。虽然本文没有试图讨论调整 Web 应用程序的细节，但本节仍提供一些使它们执行更快的指导及建议。在规划及测试您的 Web 应用程序时，请先考虑下列事项，然后再到实际联机运行的服务器上执行它们。

　　第一，ISAPI 应用程序比 Active Server Pages (ASP) 应用程序执行得更快，虽然 ASP 的开发费用远比 ISAPI 低。这两种应用程序都比 CGI 应用程序执行得更快。

　　第二，因为静态文件不会有动态文件才有的处理负载，或引起磁盘活动，所以您应该尽可能使用它们。除了使用静态文件外，您的应用程序应尽可能将处理负载推到客户端，以避免网络等待时间。如此也能节省服务器端的资源，并让更新在很段时间内完成。有个常用的范例是加一个客户端的小程序代码，来检查电子邮件地址组成是否正确。

　　另一个技巧是确定在您的实际上线运行服务器上已关闭 ASP 的侦错功能。如果启用侦错，则必须将 AppAllowDebugging Metabase 属性设为 FALSE。相关信息，请参阅〈附录 1︰性能设置〉。

　　尽可能地为所有图像及 HTML 设置「过期」标题，让它们可以存放在客户端的缓存中。相关信息，请参阅本文中的〈调整及疑难排除的建议〉小节。

　　如果 Microsoft Visual Basic_ 对象是以 Apartment 线程处理的(非 Java 或大部分 C++ 对象)，请从「ASP 应用程序及有效期」状态中删除它们。

　　只有在必要时才使用 Secure Sockets Layer (SSL)。使用 HTTPS 通讯协议比使用标准 HTTP 贵很多。请确定传送中的信息 (可能是敏感资料如信用卡号) 的价值是否值得您付出增加的费用。安全性调整问题的相关信息，请参阅本文中的〈安全性〉小节。

　　进程隔离也会影响 Web 应用程序的性能。IIS 5.0 Web 应用程序默认是在进程外的缓冲池 (中度保护) 中执行。接受进程隔离对性能的影响总比冒着服务器停机或资料遗失的风险来的安全，例如因应用程序当机而破坏它与 IIS 5.0 共享的 Ientinfo 进程时就会导致这些风险。有关这个主题的深入讨论，请参阅本文中的〈进程隔离〉小节。

　　若要增进生产环境中的数据库驱动性能，请使用 Microsoft SQL Server。由于 IIS 及 SQL Server 在足够的内存下执行的情况最好，因此请尝试将资料库存放在不同于 Web 服务的服务器上。在这种情况下，经由网络跨计算机通讯通常比单一计算机上的通讯还快。当 SQL Server 及 IIS 存放在同一台服务器上时，就会经常因为内存不足或循环不够而导致性能降低。此外，请务必建立及维护适当的索引。如此才能最小化数据库查询的输入和输出。最后一点，请尽量多利用被存储的过程(stored procedured)。它们比设计来执行相同工作的 ASP 脚本文件所需的执行时间更少，而且更容易撰写。

　　一般来说，如果您有个超过 100 行 (使用 #include 指令来计算添加文件中的程序代码行数) 的 ASP 脚本文件，请考虑建立一个 COM+ 组件来提供相同的功能。如果能撰写得很有效率，并且经过正确地的测试，则 COM++ 组件可以为同一动态页提供 20 到 30 倍处理一个脚本文件的速度。使用 #includes 测量 ASP 脚本文件最简单的方式是将扩展名从 .asp 改为 .stm，并使用您的浏览器开启 .stm 檔。您的浏览器会显示此 .asp 文件，以及来自该已包含文件(included file)中的程序代码。

　　若要最佳化动态网络应用程序的性能，很重要的一项工作是让您的应用程序正式在站点上启用前，先测试它们。执行这项工作有个很好用的工具--Web Application Stress (WAS) 工具，您可以从 Microsoft Web Application Stress Tool 站点 下载它。在这个站点上还包括专为此工具提供的教学指南及知识库。WAS 也内含在 Windows 2000 Resource Kit 附随 CD 上。本 CD 上亦有。
测量网站服务器及应用程序所需工具的相关信息，请参阅本文中的〈用来监视及测试服务器性能的工具〉小节。如需网络应用程序性能及测试该性能所需工具的链接及参照清单，请参阅本文中的〈资源〉小节。
监视及测试服务器性能的工具

　　为了支持您的性能调整及测试需求，Microsoft 提供几个工具︰有些内含在 Windows 2000 及 IIS 5.0 中、有些位于 Windows 2000 Resource Kit CD中，剩下的内容则可从 Microsoft 网站下载。「系统监视器」(先前称为 PerfMon) 内建在 Windows 2000 中，它对于监视服务器的各种性能而言是必要的。「进程及线程状态」(pstat.exe) 会显示所有执行中的进程及线程的状态。「进程树状目录」(ptree.exe) 可让您查询进程的继承树状目录，及删除本机或远程计算机上的进程。这些工具都提供在 Windows 2000 Server Resource Kit 附随 CD 上。提供在 Windows 2000 Resouce Kit 附随 CD 上的「HTTP 监视工具」会监视服务器上的 HTTP 活动，而且会在活动容量发生改变时通知您。「网络监视器」是个您可以用来维持固定网络传输量的 Windows 2000 管理工具。它不包含在默认安装中，不过使用 [控制面板] 的 [添加/删除程序] 功能可以安装它。NetStat 是个指令行工具，会侦测关于服务器目前网络连接的信息。

　　这些工具的中心是内建在 IIS 5.0 及 Windows 2000 操作系统中的「性能计数器」。开发人员也可以在他们编写的 ISAPI DLLS 或 COM 组件中添加自定义的的「性能计数器」。这些计数器可以由以上提到的一些工具直接读取，包括「系统监视器」及「Web 应用程序压力工具」和 WCAT。其中有些计数器在本文前面已作过说明，但了解哪些会关系到您的监视及测试需求是很重要的。

　　「系统监视器」是一个在Web服务器上建立性能基准，并监视您对软硬件所作的任何改变，对性能将产生哪些影响的最重要工具。「系统监视器」提供一个用户接口，让您在监视或记录时能看见性能计数器的指数。它也能让您以图形方式记录计数器活动，并设置将出现在 [事件查看器] 中的警告。「系统监视器」提供系统中每一计数器的记录。

　　「Web 应用程序压力」工具是专门为了仿真多个浏览器同时向一个网站送出网页请求而设计的。您可以使用这个工具来收集关于 Web 应用程序性能及稳定性的信息，以及服务器执行状况的信息。这个工具可以仿真利用少数的客户端机器向 Web 服务器送出大量的请求时的状态。其目的是为了建立一个与生产环境尽可能相似的环境。如此才能让您在将 Web 服务器及应用程序部署到联机运行的服务器上之前，先找出并消除其中存在的问题。

　　以上任一工具的相关信息，请参阅内含在 Windows 2000 Resource Kit 中的联机IIS 5.0 文件。指向其它信息来源的链接则内含在本文的〈资源〉小节中。

荥4晴

还能这样玩？

生鑫虹

学习了就要回帖

明礼鹏

学习