响应时间管理.doc

响应时间管理 响应时间管理非常关键。RTM可使您的业务在受到破坏之前具体化用户抱怨或评估性能问题。利用比较实际与预计性能的机制，服务水平协议变得更具有效力。此外，量化与校验性能要求的能力有助于验证新设备和未来IT规划。 PacketSeeker的RTM功能可提供性能统计、阈值监视、高级故障指示器和性能图形。这种至关重要的信息可使网络管理员： 跟踪延迟统计，实现自定义的灵活流量类别。测量单个应用、主机、子网、任何以传输方向的TCP流量类等响应时间。 将每一个响应时间分成网络延迟（传输所耗用的时间）和服务器延迟（服务器处理请求所耗用的时间）。 识别性能最差的用户和服务器。 建立可接受的标准并对性能是否符合该标准进行跟踪，通过设置速度可将良好响应从差响应（例如500ms）中划分出来。为满足指定的性能目标（例如95%）设置传输百分比。 在直观表格、图形及MIB（管理信息库）中通过XML API或作为原始数据查看当前和历史的性能数据。SNMP管理工具（例如HP OpenView）与第三方报告工具（例如InfoVista）可顺利进行集成。 测量响应时间 PacketSeeker在网络中的位置——监视所有经过的流量——能够以低成本提供精确的响应时间测量。因为PacketSeeker能够看到每一个数据包，因此它可以轻松地计算流量在客户机与服务器之间传输所用的时间、服务器所使用的时间以及PacketSeeker自身任一端所使用的时间。PacketSeeker在流量经过时只注意响应时间，而不是采集响应数据。这种简单方法提供了丰富的数据，并且不会产生网络影响和开销。 以下描述了多种PacketSeeker的响应时间测量。每一个测量至少有一个与PacketSeeker图形相关。 指标 说明 使用 总延迟 一次传输所要求的毫秒数，从客户机请求开始，到接收响应结束。 这就是大多数人说的 “响应时间”所指的意思，符合最终用户对完成传输所需时间的观点。 .验证用户对低性能的理解。 通过随时跟踪历史平均值来发现好坏倾向。 网络延迟 客户机与服务器交换数据时在传输过程中的毫秒数。 如果传输需要大量将被转换的数据，则它会被划分并在多个数据中发送。网络延迟包括所有包含在请求响应传输中的传输时间，但不包括服务器用于处理请求的时间。 确定在传输（例如，相对于服务器的开销）过程中是否由于故障而导致性能降低。 查明PacketShaper的控制功能是否能够帮助解决特定性能降低或防止其在以后出现。 服务器延迟 服务器在接收到所有需要的数据后处理客户机请求所使用的毫秒数。 服务器延迟是指服务器接收到必威体育精装版请求数据包之后和它发送第一个响应（实际响应内容，而非接收通知）之前的这段时间。这是服务器处理客户机请求所需的时间。 确定是否是服务器造成的性能降低。称为最差服务器的另一种PacketSeeker功能可识别哪些服务最慢。 正常化的 网络延迟 客户机与服务器交换数据时在传输过程中每千字节所使用的毫秒数。 如果传输需要大量将被转换的数据，则它会被划分并在多个数据中发送。由于网络延迟会随着传输的规模增加而增加，因此在比较时间时可能会产生误解。正常化的网络延迟作为一个因素可消除大小，因此进行比较是非常有用的。 为不同应用或时间段比较性能。在诊断调查中使用正常化的网络延迟和RTT来确定大型网络延迟是否由大量传输或低性能网络造成的。 往返时间(RTT) 客户机与服务器交换一个小型数据包时传输所使用的毫秒数。即使传输数据被分入到多个数据包中，RTT在客户机与服务器之间仍只包括单个数据包的一个往返。 确定大型网络延迟是否由大量传输或低性能网络造成的。例如，如果Microsoft Exchange用户突然开始使用带有特别大文件的文件共享功能，正在传输的信息而非网络状态的改变会导致性能降低。在这种情况下，网络延迟会增加但RTT不会增加。 数据包交换时间(PET) PacketSeeker数据包捕获与相应通知接收之间的毫秒数。该指标仅能反映PacketSeeker一端的网络延迟。 如果不同方负责不同网络部分时，您需要一条清楚明确的分隔线。当性能降低时，PET 会告诉您性能降低出现在何处——分隔线位于哪一端。这样每一方均有责任。没有任何一方会浪费时间设法诊断和解决它所没有的问题。 使性能指标富有意义 尽管延迟统计非常实用，但拥有一个指示性能高低的指示器会更好。像600毫秒这样的指标究竟真正意味着什么？它是好还是坏？ PacketSeeker能够建立可接受性标准并可对性能是否符合该标准进行跟踪。通过设置速度可将良好响应从差响应（例如500ms）中划分出来，也可为满足指定的性能目标（例如95%）设置传输百分比。PacketSeeker称此概念为服务水平一致性。 PacketSeeker能够以表格和图形的形式