响应时间管理Word下载.docx

响应时间管理Word下载.docx

《响应时间管理Word下载.docx》由会员分享，可在线阅读，更多相关《响应时间管理Word下载.docx（10页珍藏版）》请在冰豆网上搜索。

在流量经过时只注意响应时间，而不是采集响应数据。

这种简单方法提供了丰富的数据，并且不会产生网络影响和开销。

以下描述了多种的响应时间测量。

每一个测量至少有一个及图形相关。

指标

说明

使用

总延迟

一次传输所要求的毫秒数，从客户机请求开始，到接收响应结束。

这就是大多数人说的“响应时间”所指的意思，符合最终用户对完成传输所需时间的观点。

.验证用户对低性能的理解。

通过随时跟踪历史平均值来发现好坏倾向。

网络延迟

客户机及服务器交换数据时在传输过程中的毫秒数。

如果传输需要大量将被转换的数据，则它会被划分并在多个数据中发送。

网络延迟包括所有包含在请求响应传输中的传输时间，但不包括服务器用于处理请求的时间。

确定在传输（例如，相对于服务器的开销）过程中是否由于故障而导致性能降低。

查明的控制功能是否能够帮助解决特定性能降低或防止其在以后出现。

服务器延迟

服务器在接收到所有需要的数据后处理客户机请求所使用的毫秒数。

服务器延迟是指服务器接收到最新请求数据包之后和它发送第一个响应（实际响应内容，而非接收通知）之前的这段时间。

这是服务器处理客户机请求所需的时间。

确定是否是服务器造成的性能降低。

称为最差服务器的另一种功能可识别哪些服务最慢。

正常化的

客户机及服务器交换数据时在传输过程中每千字节所使用的毫秒数。

由于网络延迟会随着传输的规模增加而增加，因此在比较时间时可能会产生误解。

正常化的网络延迟作为一个因素可消除大小，因此进行比较是非常有用的。

为不同应用或时间段比较性能。

在诊断调查中使用正常化的网络延迟和来确定大型网络延迟是否由大量传输或低性能网络造成的。

往返时间（）

客户机及服务器交换一个小型数据包时传输所使用的毫秒数。

即使传输数据被分入到多个数据包中，在客户机及服务器之间仍只包括单个数据包的一个往返。

确定大型网络延迟是否由大量传输或低性能网络造成的。

例如，如果用户突然开始使用带有特别大文件的文件共享功能，正在传输的信息而非网络状态的改变会导致性能降低。

在这种情况下，网络延迟会增加但不会增加。

数据包交换时间（）

数据包捕获及相应通知接收之间的毫秒数。

该指标仅能反映一端的网络延迟。

如果不同方负责不同网络部分时，您需要一条清楚明确的分隔线。

当性能降低时，会告诉您性能降低出现在何处——分隔线位于哪一端。

这样每一方均有责任。

没有任何一方会浪费时间设法诊断和解决它所没有的问题。

使性能指标富有意义

尽管延迟统计非常实用，但拥有一个指示性能高低的指示器会更好。

像600毫秒这样的指标究竟真正意味着什么？

它是好还是坏？

能够建立可接受性标准并可对性能是否符合该标准进行跟踪。

通过设置速度可将良好响应从差响应（例如500）中划分出来，也可为满足指定的性能目标（例如95%）设置传输百分比。

称此概念为服务水平一致性。

能够以表格和图形的形式显示当前或历史的所有性能指标。

监视器响应时间窗口（）显示了每个分类的当前性能统计表。

另一个窗口提供了及单个分类相关的所有性能指标和图形，以便让您来定义可接受的每个分类的性能。

各种图形均可随时为一个或多个流量分类描述网络、服务器和总延迟。

您可以查看实际延迟（传输所耗用的时间）、数据包往返时间（仅一个数据包经过网络所耗用的时间）或正常化数据包时间（标准规模的传输所耗用的时间）。

例如，下列传输延迟图形显示了响应时间由于频繁峰值而出现的偶发性变缓。

此外，您还可以看到，这一问题的出现不是由服务器造成的，而是网络造成的。

如果这是一个关键型应用的图形，很明显，其性能需要得到相应的提高。

由此，加入的带宽控制是必需的。

最后，服务水平一致性图形可使您了解您在建立符合应用的性能标准方面一直以来的工作情况。

例如，在该图中，您可以看到，除了几天以外，性能都没有保持在性能标准以内。

再次表明，可能的控制功能是适宜的。

的响应时间优势

在响应时间上的优势主要基于两个方面：

不需要更改变任何设置，以及它不会成为一个故障点。

可避免普通缺陷，其中包括：

∙对应用的修改

无需额外的调用或应用软件的素材。

∙桌面及服务器更改

无需在客户机桌面或任何服务器上装载任何东西。

∙模拟流量开销

不会产生仅用来定时响应的无关应用请求，它也不会发布。

如果需要的话，它可以产生合成传输，但可以在不产生模拟流量的情况下计算所有响应时间指标。

∙路由器重新配置或拓扑更改

不需要更改路由器配置、协议、服务器、桌面或拓扑。

∙位置限制

可测量网络中各个位置的性能，只要一发现流量便会对其进行测量。

它可以位于拓扑的客户机端或服务器端。

如果因特网将客户机及服务器分开，在哪一端部署都无关紧要。

∙数据采集开销

使用恒量的数据下载，不会致使网络负担过重。

合成传输（）

根据您的判断，可定期启动或其它传输，以便校验关键主机的可用性。

这一行动类似于调度的或轮询，但需凭借如下这些重要的优势：

∙的详细传输行为分析和响应时间可应用于合成传输，从而具有随时描述网络和主机行为的能力。

这一信息比了解设备是否会简单响应更加有用。

∙当位于网络边缘时，轮询在局域网，消耗的带宽量将更少，因此它会变得更加频繁，并可减轻带宽负担。

∙合成传输可确定服务或应用是否正在进行，而非仅仅确定服务器是否正在响应。

它们可提供更高级的“可用性”评估。

∙分布式的是收集本地的可用信息，并能够通过电子邮件、或系统日志消息将有益情况或问题转发给中心位置。

它还消除了通过中央管理平台进行远距离轮询的需要。

附加工具

提供的各种图形和功能，可帮助您监视和诊断应用性能。

在其它章节中将总结和详细说明其中的部分功能。

诊断帮助

在确定了并非是其所期望的应用性能后，可提供有助于您诊断工作的各种图形。

例如健康图形可对服务器启动、中断以及忽略或拒绝的连接数进行比较；

网络效率图形揭示了由于重传而浪费的带宽量；

各种带宽应用图形可使您将性能及负载条件联系起来。

这些图形和工具在“网络性能分析”一章中进行了详细阐述。

事件及通知

在监视或分析性能时，您可能希望了解大量关键情况信息，而不必不停地检查它们的状态。

利用，您可以自动检测有益的条件，并且通过电子邮件、记录信息到服务器或通知自己和其它相关人员。

例如，当重传出现而消耗30%的网络流量时，您可以给网络管理员发送电子邮件。

或者如果您的响应时间超过了1.5秒而耗用了20%　以上的时间时，您可以给您的警报机构发送。

您可以：

∙定义对您有利的事件或使用大量预定义事件的其中一个。

∙为关键性能变量配置阈值，这在定时间隔期间是非常充足的。

∙监视事件并自动进行触发式通知。

∙通设设置每天最多只发送多少条消息和重新分配值来避免通知患难。

详情请参阅“生成及使用报告”中的事件工具部分。

计算延迟——技术方面的细节

可跟踪客户机－服务器传输的过程，并可使用连接信息来将交换的一部分及其它部分区别开来。

以下图形有助于阐明对连接组件的深刻理解。

该图是标准的通讯图表，显示了网络传输随时间推移的过程。

箭头指明了通过客户机及服务器之间的网络数据包。

随着您访问量的增加，时间也会增加，连续的事件时间标注为，T1代表第一个事件，T22代表最后一个事件。

在T1时间时客户机启动的及服务器连接。

T2时间时注意到并将其传递给服务器。

T3时间时服务器做出响应。

T4时间时注意到，并像往常一样对其进行传递。

经常在内核中和没有内容交换时快速做出响应。

几乎实时紧随。

因此，T4时间减去T2时间可准确测出及服务器之间的往返网络延迟。

这种互换产生了第一个数值，即服务器的传输延迟（）：

=T4–T2

T5时间时，客户机接收并发布三次握手的最终。

T6时间时，注意到，并将其传递给服务器。

T5时间时客户机对的接收及其自身相应的之间没有发生处理的这种假设是合理的。

T6时间减去T4时间可准确测出客户机及之间的往返网络延迟。

客户机延迟（）为：

=T6–T4

将服务器传输延迟及客户机延迟加起来将得出客户机及服务器之间单个往返的总延迟。

（往返时间）=+

确定服务器延迟

在T8时客户机启动请求，T9时间时到达。

较大的请求会被分成多个数据包。

为了简化视图，图表（上图）没有把服务器响应的画出，因为这些不是所需要计算的资料。

在T11时间发送的最后请求数据包对其标记进行了设置，就指明这是最后一个数据包。

同时也注意到T12为这个数据包最后请求时间。

当最后一个请求数据包在T13时间到达服务器后，服务器将集合请求，执行请求所要求的任何处理，并集合响应。

T14时间时服务器将发送第一个数据包（属于可能的多个响应数据包）。

T14时间减去T13时间将得出请求所需的实际服务器处理时间，但这些时间是所无法了解的。

知道在它看到最后一个请求数据包之后及看到第一个响应数据包之前所出现的服务器处理时间（T15时间减去T12时间）。

此外，它还知道这段间隔时间的另一个组成部分是往返于到服务器的传输时间。

这样很容易地获得了这些数字——服务器传输延迟（）时间值。

此外，还存在少量在响应数据包中将位数串连起来以及为使其形成位流而进行准备所花费的时间。

这段时间不包括在最初的服务器传输延迟中，因为及数据包非常小。

知道数据包的大小，可计算相应的准备时间

（1），并在将总数从时差中减去前把这段准备时间加到中。

服务器延迟=（T15–T12）–（+1）

确定总延迟

传输的终止对计算总延迟非常关键，但传输结束的时间不是始终都明显的。

服务器中标记及客户机中相应的两者的组合会频繁地发送结束信号。

但较长的传输经常会在整个传输过程中插入标记。

除监视标记外，还使用定时器来跟踪传输并采用以下规则：

∙如果标记指示传输已经结束，而服务器仍继续发送更多数据，则定时器会不断

将定时时间提前。

∙如果客户机发送一项新的请求，则会终止上一次传输并记录所指明的上一次时间。

∙如果服务器或客户机中都没有行动，则会认为传输已完成，同时将记录所指明的上次时间。

∙当连接终止时，将查看，并记录所指明的上次时间。

通过使用这些技术，可在T18时间时指明上一次响应数据包，确保它发现请求数据包的全部所需，并校验上次响应数据包确实表示传输的终止。

当客户机在T19时间接收到最后一个响应数据包后，它会发送一个。

在T21时间时到达。

客户机根据响应时间开始发送第一个请求数据包（T8）并终止最后一个响应数据包（T20）的接收。

在到T21时间前，将该时间间隔视为T9时间。

尽管以客户机的观点来看这是非常接近的评估，但它需要一定的额外准备时间来串连第一个请求数据包，因此可假设它比最后的还要大。

由于知道数据包大小的区别，因此它可以计算这种较小的差值

（2）。

总延迟=（T21–T9）+2

一旦获得服务器延迟和总延迟，它便可计算传输在传输过程中所耗用的总时间值。

网络延迟=（总延迟）–（服务器延迟）

尽管代表一次往返的传输时间，但网络延迟却可反映传输的所有传输时间。

如果传输数据较大，则多个数据包需要往返于服务器。

只有网络延迟可反映这种开销。

网络延迟不必是偶倍数的，因为发送多个数据包不是连续进行的，而是倾向于重叠改变次数。

此外，因为网络及总延迟是传输规模的产物，因此无法比较时间和测量。

正如您所看到的，利用其中间位置在传输期间进行时间及大小的观察。

然后，它结合基础来提供精确的性能数字。