· web service: maximum connections 及 web service: total connection attempts 。如果您正在计算机上执行的其他服务也使用网络连接，则应监视「web service: maximum connections」及「web service: total connection attempts」计数器，以检查您的web服务器是否能够尽可能地使用它需要的连接数目。请记得将这些数字与内存及处理器使用量作比较，如此才能确定连接就是问题，而不是其它组件有问题。
磁盘最佳化
因为 iis 5.0 会将记录文件写入磁盘上，所以在一般磁盘活动中，甚至会有高达 100 % 的客户端缓存存取次数。一般来说，如果有记录以外的大量磁盘读取活动，即表示系统上有其它区域需要调整。例如，硬件分页错误会导致大量的磁盘活动，但它们表示 ram 不足。
存取内存比存取磁盘快约 1 百万倍；无疑地，通过搜寻硬盘来响应请求将降低性能。您主控的网站类型对硬磁盘搜寻的频率影响很大。如果您的网站上有个随机存取的超大型文件集、如果网站上的文件大多是超大型，或如果 ram 的容量很小，则 iis 便无法在 ram 中维护文件的复本，供更快速的存取。
当您的服务器忙碌时您通常会使用「physical disk」计数器来监视，磁盘读取次数的允许范围。如果 ram 够大，则大部分的连接会导致缓存存取，除非您有个存放在同一台服务器上的数据库，而且用户端正在提出不同的查询。这种情况会阻止缓存处理。请注意记录也会导致磁盘瓶颈。如果您的服务器上没有明显与大量磁盘有关的问题，但却看见大量的磁盘活动，则应立即检查服务器上的 ram 容量，以确定是否有足够的内存。
若要确定磁盘存取的频率，请记录下列计数器︰
· processor: % processor time, network interface connection: bytes total/sec及physicaldisk: % disk time。如果这三个计数器的值都很高，则硬盘不会引起站点的瓶颈。但是，如果「% disk time」的值很高，但处理器及网络连接并没有饱和，则硬盘可能会造成瓶颈。如果在您的服务器上没有启用「physical disk」计数器，请开启指令行，并使用diskperf -yd 指令。
安全性
在性能与用户关心的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 请求。
//
文章来源于领测软件测试网 https://www.ltesting.net/