响应时间管理.doc

响应时间管理 响应时间管理非常关键。RTM可使您的在有PacketSeeker的RTM功能可提供性能统计、阈值监视、高级故障指示器和性能图形。这种至关重要的信息可使网络管理员： 跟踪延迟统计，实现自定义的灵活流量类别。测量单个应用、主机、子网、任何以传输方类 将每一个响应时间分成网络延迟（传输所耗用的时间）和服务器延迟（服务器处理请求所耗用的时间）。 识别性能最差 建立可接受的，通过差为的设置传输 在直观表格、的SNMP管理工具（例如HP OpenView）与第三方报告工具（例如InfoVista）可顺利进行集成。 测量响应时间 PacketSeeker在网络中的位置——监视所有经过的流量——能够以低成本提供精确的响应时间测量。因为PacketSeeker能够看到每一个数据包，因此它可以轻松地计算流量在客户机与服务器之间传输所用的时间、服务器所使用的时间以及PacketSeeker自身任一端所使用的时间。PacketSeeker在流量经过时只注意响应时间，而不是采集响应数据。这种简单方法提供了丰富的数据，并且不会产生网络影响和开销。 以下描述了多种PacketSeeker的响应时间测量。每一个测量至少有一个与PacketSeeker图形相关。 指标 说明 使用 总延迟 一次传输传输.验证用户对低性能的理解。 通过随时跟踪历史平均值来发现好坏倾向。 网络延迟 客户机与服务器交换数据时在传输过程中的毫秒数。 如果传输的PacketShaper的控制功能是否能够帮助解决特定性能降低或防止其在以后出现。 服务器延迟 服务器在接收到所有需要的数据后处理客户机请求所使用的毫秒数。 服务器延迟是指服务器接收到最新请求数据包之后和它发送第一个响应（实际响应内容，而非接收通知）之前的这段时间。这是服务器处理客户机请求所需的时间。 确定是否是服务器造成的性能降低。称为最差服务器的另一种PacketSeeker功能可识别哪些服务最慢。 正常化的 网络延迟 客户机与服务器交换数据时在传输过程中每千字节所使用的毫秒数。 如果传输传输大小量传输 往返时间(RTT) 客户机与服务器交换一个小型数据包时传输所使用的毫秒数。即使传输 确定大型网络延迟是否由大量传输Microsoft Exchange用户突然开始使用带有特别大文件的文件共享功能，正在传输的信息而非网络状态的改变会导致性能降低。在这种情况下，网络延迟会增加但RTT不会增加。 数据包交换时间(PET) PacketSeeker数据包捕获与相应通知接收之间的毫秒数。该指标仅能反映PacketSeeker一端的网络延迟。 如果不同方负责不同网络部分时，您需要一条清楚明确的分隔线。当性能降低时，PET 会告诉您性能降低出现在何处——分隔线位于哪一端。这样每一方均有责任。没有任何一方会浪费时间设法诊断和解决它所没有的问题。 使性能指标富有意义 尽管延迟统计非常实用，但拥有一个指示性能高低的指示器会更好。像600毫秒这样的指标究竟真正意味着什么？它是好还是坏？ PacketSeeker能够建立可接受性标准并可对性能是否符合该标准进行跟踪。通过差也可为的设置传输PacketSeeker称此概念为服务水平一致性。 PacketSeeker能够以表格和图形的形式显示当前或历史的所有性能指标。 监视器响应时间窗口(Monitor Reponse Time)显示了每个分类当与分类相关的性能个分类的 各种图形均可随时为一个或多个流量分类描述网络、服务器和总延迟。您可以查看实际延迟（传输所耗用的时间）、数据包往返时间（仅一个数据包经过网络所耗用的时间）或正常化数据包时间（标准规模的传输所耗用的时间）。 例如，下列传输延迟图形显示了响应时间由于频繁峰值而出现的偶发性变缓。此外，您还可以看到，这一问题的出现不是由服务器造成的，而是网络造成的。如果这是一个关键型应用的图形，很明显，其性能需要得到相应的提高。由此，加入PacketShaper的带宽控制是必需的。 最后，服务水平一致性图形可使您了解您在建立符合应用的性能标准方面一直以来的工作情况。例如，在该图中，您可以看到，除了几天以外，性能都没有保持在性能标准以内。再次表明，可能PacketShaper的控制功能是适宜的。 PacketSeeker的响应时间优势 PacketSeeker在响应时间上的优势主要基于两个方面：不需要更改变任何设置，以及它不会成为一个故障点。PacketSeeker可避免普通缺陷，其中包括： 对应用的修改 PacketSeeker无需额外的API调用或应用软件的素材。 桌面与服务器更改 PacketSeeker无需在客户机桌面或任何服务器上装载任何东西。 模拟流量开销 PacketS