分类：
2008-10-16 18:43:36
性
在性能与用户关心的Web性之间找出平衡点是您将面对的重要问题之一，尤其是当您经营电子商务网站更是如此。因为安全的网络通讯比不安全的网络通讯需要更多资源，所以知道何时应使用不同的安全技术 (如 SSL 通讯或 IP 地址检查)，以及何时不该使用它们是很重要的。例如，您的首页或一个搜寻结果页几乎不需要通过 SSL 执行。但是，当用户进入一个结帐或采购网页时，您就需要确定该页是安全的。
如果使用 SSL，则请注意，建立初始连接比重新连接已经在 SSL 有效期缓存中的安全信息的成本要高上五倍。SSL 有效期缓存的默认超时时间，已经从 NT 4.0 中的 2 分钟改变为在 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 请求。
[1]
