使用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 请求。

如果你还在为自己网站服务器这样那样的问题而烦恼的话、可以联系我，我来帮你排忧解难！

联系电话：       0371-56665672          QQ: