响应时间管理.pdf

《响应时间管理.pdf》由会员分享，可在线阅读，更多相关《响应时间管理.pdf（9页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、响应时间管理响应时间管理响应时间管理非常关键。RTM 可使您的业务在受到破坏之前具体化用户抱怨或评估性能问题。利用比较实际与预计性能的机制，服务水平协议变得更具有效力。 此外，量化与校验性能要求的能力有助于验证新设备和未来IT 规划。PacketSeeker 的 RTM 功能可提供性能统计、阈值监视、高级故障指示器和性能图形。这种至关重要的信息可使网络管理员：1.2.3.4.跟踪延迟统计，实现自定义的灵活流量类别。测量单个应用、主机、子网、任何以传输方向的 TCP 流量类等响应时间。将每一个响应时间分成网络延迟（传输所耗用的时间）和服务器延迟（服务器处理请求所耗用的时间）。识别性能最差的用户和

2、服务器。建立可接受的标准并对性能是否符合该标准进行跟踪，通过设置速度可将良好响应从差响应（例如 500ms）中划分出来。为满足指定的性能目标（例如 95%）设置传输百分比。在直观表格、图形及 MIB（管理信息库）中通过 XML API 或作为原始数据查看当前和历史的性能数据。SNMP 管理工具（例如 HP OpenView）与第三方报告工具（例如 InfoVista）可顺利进行集成。5.测量响应时间测量响应时间PacketSeeker在网络中的位置监视所有经过的流量能够以低成本提供精确的响应时间测量。因为 PacketSeeker 能够看到每一个数据包， 因此它可以轻松地计算流量在客户机与服务

3、器之间传输所用的时间、 服务器所使用的时间以及PacketSeeker 自身任一端所使用的时间。PacketSeeker 在流量经过时只注意响应时间，而不是采集响应数据。这种简单方法提供了丰富的数据，并且不会产生网络影响和开销。以下描述了多种 PacketSeeker 的响应时间测量。 每一个测量至少有一个与PacketSeeker 图形相关。指标指标说明说明一次传输所要求的毫秒数，从客户机请求开始，到接收响应结束。使用使用.验证用户对低性能的理解。通过随时跟踪历史平均值来发现好坏倾向。总延迟总延迟这就是大多数人说的 “响应时间”所指的意思，符合最终用户对完成传输所需时间的观点。客户机与服务器

4、交换数据时在传输过程中的毫秒数。网络延迟网络延迟如果传输需要大量将被转换的数据，则它会被划分并在多个数据中发送。网络延迟包括所有包含在请求响应传输中的传输时间，但不包括服务器用于处理请求的时间。服务器在接收到所有需要的数据后处理客户机请求所使用的毫秒数。服务器延迟服务器延迟服务器延迟是指服务器接收到最新请求数据包之后和它发送第一个响应（实际响应内容，而非接收通知）之前的这段时间。这是服务器处理客户机请求所需的时间。客户机与服务器交换数据时在传输过程中每千字节所使用的毫秒数。正常化的正常化的网络延迟网络延迟如果传输需要大量将被转换的数据，则它会被划分并在多个数据中发送。由于网络延迟会随着传输的规

5、模增加而增加，因此在比较时间时可能会产生误解。正常化的网络延迟作为一个因素可消除大小，因此进行比较是非常有用的。客户机与服务器交换一个小型数据包时传输所使用的毫秒数。即使传输数据被分入到多个数据包中，往往 返返 时时 间间(RTT)(RTT)RTT 在客户机与服务器之间仍只包括单个数据包的一个往返。确定在传输（例如，相对于服务器的开销）过程中是否由于故障而导致性能降低。查明 PacketShaper 的控制功能是否能够帮助解决特定性能降低或防止其在以后出现。确定是否是服务器造成的性能降低。称 为 最 差 服 务 器 的 另 一 种PacketSeeker 功能可识别哪些服务最慢。为不同应用或时

6、间段比较性能。在诊断调查中使用正常化的网络延迟和RTT 来确定大型网络延迟是否由大量传输或低性能网络造成的。确定大型网络延迟是否由大量传输或低性能网络造成的。例如，如果Microsoft Exchange 用户突然开始使用带有特别大文件的文件共享功能，正在传输的信息而非网络状态的改变会导致性能降低。在这种情况下，网络延迟会增加但 RTT 不会增加。PacketSeeker 数据包捕获与相应通知接收之间的毫秒数。该指标仅能反映 PacketSeeker 一端的网络延数数据据包包交交换换时间时间(PET)(PET)迟。如果不同方负责不同网络部分时，您需要一条清楚明确的分隔线。当性能降低时， PET

7、 会告诉您性能降低出现在何处分隔线位于哪一端。这样每一方均有责任。没有任何一方会浪费时间设法诊断和解决它所没有的问题。使性能指标富有意义使性能指标富有意义尽管延迟统计非常实用， 但拥有一个指示性能高低的指示器会更好。 像 600 毫秒这样的指标究竟真正意味着什么？它是好还是坏？PacketSeeker 能够建立可接受性标准并可对性能是否符合该标准进行跟踪。通过设置速度可将良好响应从差响应（例如500ms）中划分出来，也可为满足指定的性能目标（例如95%）设置传输百分比。PacketSeeker 称此概念为服务水平一致性。PacketSeeker 能够以表格和图形的形式显示当前或历史的所有性能指

8、标。监视器响应时间窗口(Monitor Reponse Time)显示了每个分类的当前性能统计表。 另一个窗口提供了与单个分类相关的所有性能指标和图形，以便让您来定义可接受的每个分类的性能。各种图形均可随时为一个或多个流量分类描述网络、 服务器和总延迟。 您可以查看实际延迟（传输所耗用的时间） 、数据包往返时间（仅一个数据包经过网络所耗用的时间）或正常化数据包时间（标准规模的传输所耗用的时间） 。例如，下列传输延迟图形显示了响应时间由于频繁峰值而出现的偶发性变缓。 此外，您还可以看到，这一问题的出现不是由服务器造成的， 而是网络造成的。如果这是一个关键型应用的图形，很明显，其性能需要得到相应的

9、提高。由此，加入 PacketShaper 的带宽控制是必需的。最后， 服务水平一致性图形可使您了解您在建立符合应用的性能标准方面一直以来的工作情况。例如，在该图中，您可以看到，除了几天以外，性能都没有保持在性能标准以内。再次表明，可能 PacketShaper 的控制功能是适宜的。PacketSeekerPacketSeeker 的响应时间优势的响应时间优势PacketSeeker 在响应时间上的优势主要基于两个方面：不需要更改变任何设置，以及它不会成为一个故障点。PacketSeeker 可避免普通缺陷，其中包括：对应用的修改对应用的修改 PacketSeeker 无需额外的 API 调用

10、或应用软件的素材。桌面与服务器更改桌面与服务器更改 PacketSeeker 无需在客户机桌面或任何服务器上装载任何东西。模拟流量开销模拟流量开销PacketSeeker 不会产生仅用来定时响应的无关应用请求， 它也不会发布 ping。如果需要的话，它可以产生合成传输，但可以在不产生模拟流量的情况下计算所有响应时间指标。路由器重新配置或拓扑更改路由器重新配置或拓扑更改 PacketSeeker 不需要更改路由器配置、协议、服务器、桌面或拓扑。位置限制位置限制PacketSeeker 可测量网络中各个位置的性能，只要一发现流量便会对其进行测量。它可以位于拓扑的客户机端或服务器端。如果因特网将客户

11、机与服务器分开，在哪一端部署 PacketSeeker 都无关紧要。数据采集开销数据采集开销PacketSeeker 使用恒量的数据下载，不会致使网络负担过重。合成传输（合成传输（Synthetic TransactionSynthetic Transaction）根据您的判断，PacketSeeker 可定期启动 web 或其它 TCP 传输，以便校验关键主机的可用性。这一行动类似于调度的ping 或 SNMP 轮询，但需凭借如下这些重要的优势：PacketSeeker 的详细传输行为分析和响应时间可应用于合成传输， 从而具有随时描述网络和主机行为的能力。这一信息比了解设备是否会简单响应pi

12、ng 更加有用。当 PacketSeeker 位于网络边缘时，轮询在局域网，消耗的带宽量将更少，因此它会变得更加频繁，并可减轻带宽负担。合成传输可确定服务或应用是否正在进行，而非仅仅确定服务器是否正在响应。它们可提供更高级的“可用性”评估。分布式的 PacketSeeker 是收集本地的可用信息，并能够通过电子邮件、SNMP Trap 或系统日志消息将有益情况或问题转发给中心位置。它还消除了通过中央管理平台进行远距离轮询的需要。附加工具附加工具PacketSeeker 提供的各种图形和功能，可帮助您监视和诊断应用性能。在其它章节中将总结和详细说明其中的部分功能。诊断帮助诊断帮助在确定了并非是其

13、所期望的应用性能后， PacketSeeker可提供有助于您诊断工作的各种图形。例如 TCP 健康图形可对服务器启动、 中断以及忽略或拒绝的TCP 连接数进行比较； 网络效率图形揭示了由于重传而浪费的带宽量； 各种带宽应用图形可使您将性能与负载条件联系起来。这些图形和工具在“网络性能分析”一章中进行了详细阐述。事件与通知事件与通知在监视或分析性能时，您可能希望了解大量关键情况信息，而不必不停地检查它们的状态。利用 PacketSeeker，您可以自动检测有益的条件，并且通过电子邮件、记录信息到Syslog 服务器或 SNMP Trap通知自己和其它相关人员。例如，当重传出现而消耗30% 的网络

14、流量时，您可以给网络管理员发送电子邮件。或者如果您的 SAP 响应时间超过了 1.5 秒而耗用了 20%以上的时间时，您可以给您的HPOpenView警报机构发送 SNMP Trap。您可以：定义对您有利的事件或使用大量预定义事件的其中一个。为关键性能变量配置阈值，这在定时间隔期间是非常充足的。监视事件并自动进行触发式通知。通设设置每天最多只发送多少条消息和重新分配值来避免通知患难。详情请参阅“生成与使用报告”中的事件工具部分。计算延迟技术方面的细节计算延迟技术方面的细节PacketSeeker 可跟踪客户机服务器传输的PacketSeeker orPacketSeeker or过程，并可使用

15、 TCP 连接信息来将交换的ClientClientPacketShaperPacketShaperServerServerPacketShaperPacketShaper一部分与其它部分区别开来。 以下图形有助SYNT1于阐明 PacketSeeker 对连接组件的深刻理T2解。T3SYN-ACKT4该图是标准的 TCP 通讯图表，显示了网络传输随时间推移的过程。 箭头指明了通过客ACKT5T6Request d户机与服务器之间的网络数据包。 随着您访ata(theresnopushflag, somorecominT8T7问量的增加，时间也会增加，连续的事件时g)T9间标注为 TN，T1

16、代表第一个事件，T22 代Repeated data packT10ets as neeACKs are e表最后一个事件。ded to accliminated fommodateor diagram length; clarityRequest datawithpT11ushflag在T1时间时客户机启动的SYN与服务器连T12接。T2 时间时 PacketSeeker 注意到 SYN 并T13将其传递给服务器。T3 时间时服务器做出dataT14ResponseSYN-ACK 响应。T4 时间时 PacketSeeker 注T15shflag意到 SYN-ACK，并像往常一样对其进行传t

17、awithpuT16T17adesnoRespT18递。T19ACKT20TCP 经常在内核中和没有内容交换时快速T21做出 SYN-ACK 响应。SYN-ACK 几乎实时T22紧随 SYN。 因此， T4 时间减去 T2 时间可准确测出PacketSeeker与服务器之间的往返网络延迟。这种互换产生了第一个数值，即服务器的传输延迟（STD） ：STD = T4 T2T5 时间时，客户机接收 SYN-ACK 并发布三次握手的最终 ACK。T6 时间时，PacketSeeker注意到 ACK，并将其传递给服务器。T5时间时客户机对SYN-ACK的接收与其自身相应的ACK之间没有发生处理的这种假设

18、是合理的。T6 时间减去 T4 时间可准确测出客户机与PacketSeeker 之间的往返网络延迟。 客户机延迟(CTD)为：CTD = T6 T4将服务器传输延迟与客户机延迟加起来将得出客户机与服务器之间单个往返的总延迟。RTT （往返时间） = STD + CTD确定服务器延迟确定服务器延迟在 T8 时客户机启动请求，T9 时间时到达 PacketSeeker。较大的请求会被分成多个数据包。为了简化视图，TCP 图表（上图）没有把服务器响应的 ACK 画出，因为这些 ACK 不是PacketSeeker 所需要计算的资料。在 T11 时间发送的最后请求数据包对其 Push 标记进行了设置，

19、就指明这是最后一个数据包。 PacketSeeker 同时也注意到 T12 为这个数据包最后请求时间。当最后一个请求数据包在 T13 时间到达服务器后，服务器将集合请求，执行请求所要求的任何处理，并集合响应。 T14 时间时服务器将发送第一个数据包（属于可能的多个响应数据包） 。T14 时间减去 T13 时间将得出请求所需的实际服务器处理时间，但这些时间是PacketSeeker 所无法了解的。PacketSeeker知道在它看到最后一个请求数据包之后与看到第一个响应数据包之前所出现的服务器处理时间（T15 时间减去 T12 时间） 。此外，它还知道这段间隔时间的另一个组成部分是往返于 Pac

20、ketSeeker 到服务器的传输时间。 这样 PacketSeeker 很容易地获得了这些数字服务器传输延迟(STD)时间值。此外，还存在少量在响应数据包中将位数串连起来以及为使其形成位流而进行准备所花费的时间。 这段时间不包括在最初的服务器传输延迟中， 因为 SYN 与 ACK 数据包非常小。PacketSeeker 知道数据包的大小，可计算相应的准备时间（1） ，并在将总数从时差中减去前把这段准备时间加到STD 中。服务器延迟 = （T15 T12） （STD + 1）确定总延迟确定总延迟传输的终止对计算总延迟非常关键，但传输结束的时间不是始终都明显的。服务器中 Push标记与客户机中相

21、应的ACK 两者的组合会频繁地发送结束信号。但较长的传输经常会在整个传输过程中插入 Push 标记。除监视 Push 标记外，PacketSeeker 还使用定时器来跟踪传输并采用以下规则：如果 Push 标记指示传输已经结束，而服务器仍继续发送更多数据，则定时器会不断将定时时间提前。如果客户机发送一项新的请求，则 PacketSeeker 会终止上一次传输并记录所指明的上一次时间。如果服务器或客户机中都没有行动，则 PacketSeeker 会认为传输已完成，同时将记录所指明的上次时间。当连接终止时，PacketSeeker 将查看 FIN，并记录所指明的上次时间。通过使用这些技术，Pack

22、etSeeker 可在 T18 时间时指明上一次响应数据包，确保它发现请求数据包的全部所需 ACK，并校验上次响应数据包确实表示传输的终止。当客户机在 T19 时间接收到最后一个响应数据包后， 它会发送一个 ACK。ACK 在 T21 时间时到达 PacketSeeker。客户机根据响应时间开始发送第一个请求数据包（ T8）并终止最后一个响应数据包（T20）的接收。在到 T21 时间前，PacketSeeker 将该时间间隔视为 T9 时间。尽管以客户机的观点来看这是非常接近的评估， 但它需要一定的额外准备时间来串连第一个请求数据包，因此可假设它比最后的ACK 还要大。由于 PacketSee

23、ker 知道数据包大小的区别，因此它可以计算这种较小的差值（2） 。总延迟 = （T21 T9） + 2PacketSeeker 一旦获得服务器延迟和总延迟，它便可计算传输在传输过程中所耗用的总时间值。网络延迟 = （总延迟） （服务器延迟）尽管 RTT 代表一次往返的传输时间，但网络延迟却可反映传输的所有传输时间。如果传输数据较大，则多个数据包需要往返于服务器。 只有网络延迟可反映这种开销。 网络延迟不必是偶倍数的 RTT，因为发送多个数据包不是连续进行的，而是倾向于重叠改变次数。此外，因为网络与总延迟是传输规模的产物，因此无法比较ping 时间和 RTM测量。正如您所看到的，PacketSeeker 利用其中间位置在传输期间进行时间与大小的观察。然后，它结合 TCP 基础来提供精确的性能数字。