【转】Loadrunner案例:某省电信公司业务系统的性能测试

上一篇 / 下一篇  2017-10-20 16:31:35 / 个人分类:性能测试

一、项目背景

该案例是某省电信公司的业务系统的性能测试。该业务系统用于管理省电信公司的所有电信交换机设备,业务系统的重点在于4个方面:从交换机定期获取并处理话务报告;接收交换机发出的告警消息;允许用户通过应用界面对交换机进行操作(发送命令);允许其他业务系统发送的交换机操作要求通过网关的处理后转换成相应的交换机命令并下发。

由于该业务系统是电信运营商的核心支撑业务系统,因此用户对该系统的稳定性非常关注,要求系统能够7×24小时不间断运行,在最终决定的系统方案中,也为该系统的采集服务器进行了N+1的冗余配置,为应用服务器和数据库服务器进行了1+1的冗余配置。

对业务系统的性能测试是在开发接近完成时进行的,主要目的包括几个方面:验证系统是否达到了预期的性能指标;验证系统是否能稳定运行;验证系统的失效恢复方案是否有效;在测试过程中有针对性的进行部分调优工作,以保证系统能够达到预期的性能要求。

性能测试工具Loadrunner

点击下载

二、项目特点

该项目的最大特点是选用的架构复杂,使用的协议基本上都是基于TCP/IP的自定义协议。该业务系统需要使用多种中间平台,所以架构设计为一个复杂的分层结构。另一方面,应用各模块之间的通信方式也比较复杂,考虑到与其他系统的接口,该业务系统采用了多种基于TCP/IP的自定义协议。

对性能测试来说,本系统的一个重要特点是系统涉及较多的外部设备(交换机等),而这些设备由于是用户的实际生产设备,不可能按照测试的要求对其进行设置和操作,必须通过一定的手段来模拟这些外部设备。

该系统的另一个特点是性能测试关注的内容中交互界面很少,除了用户下发命令外,其他的性能测试关注内容都没有人工交互的干预,因此,测试中对系统性能的体现主要是业务处理能力,只在用户下发命令这一个方面用响应时间来描述系统性能表现。

图1简单描述了该业务系统。

图1

从图1中可以看到,该业务系统是一个全省集中的处理系统,系统管理的话务交换机设备通过MOXA设备(1)转接或是直接通过省电信公司的网络传输的话务交换机设备通过MOXA到省电信中心的中心机房,所有服务器都放置在中心机房,通过网络交换设备进入电信公司的网络。为了保证系统的稳定运行,将服务器进行了分组管理,每组都设置了一台设备进行热备份。

由于这里给出的话务交换机设备都是实际在网运行的设备,因此,在实际的测试中,不可能利用这些实际的话务交换机设备进行测试。本业务系统管理的话务交换机数量较多,在全省规模下,有600台左右的实际设备。

此外,该性能测试的部分性能目标在需求和设计中进行了明确的定义,性能测试目标的确定可以通过对需求和设计的分析获取,这也是本案例的重要特点之一。

三、性能测试过程

本节描述性能测试的全过程,根据本书第5章的性能测试过程描述,按照PTGM模型分别对性能测试的各阶段进行阐述。

测试前期准备

在了解该项目的基本状况之后,首先开始测试前期准备工作。

1、系统基础功能验证

本案例中描述的性能测试安排在功能验收测试之后,因此在性能测试中不需要额外安排基础功能验证。

2、组建测试团队

根据该项目的具体情况,建立一个7人的团队负责本次测试工作。团队的7个成员中,1名是数据库工程师,1名是系统工程师,3名是性能测试设计和分析人员,2名是性能测试开发和实施人员。

在测试开始之前,已经预计到该系统的性能测试可能需要投入较大力量进行测试方案设计,其次还需要自行实现部分测试工具,因此,安排了3名性能测试设计和分析人员与2名性能测试开发和实施人员。

3、测试工具需求确认

考虑到系统测试的要求,该系统面临的最大问题在于需要模拟现有设备和系统使用的协议多,因此,综合项目的状况,最终确定的测试工具需求如下:

  • 支持TCP/IP协议层上的测试。
  • 能够方便地模拟现有设备,由于我们关注的是现有设备的定时发送报告、不定时发送告警和接受下发命令(包括用户和其他业务系统下发命令),因此对设备的模拟至少需要包括能定期发送指定数据、能随机发送指定数据并满足一定的频度要求、能接受命令并给出响应。
  • 能够记录每个操作消耗的时间,便于进行性能分析。
  • 考虑到用户的稳定性要求,工具要求能够监控系统是否稳定。

4、性能预备测试

性能预备测试用于对系统建立直观的认识,我们安排接入少量设备,并对少量设备接入后的系统运行进行体验,体验结果表明,在少量设备接入的情况下,系统能够顺利地完成话务报告数据处理,能够在3秒之之内将设备产生的告警呈现在系统界面上。

测试工具引入

测试工具的引入对本案例来说是一个比较重要的过程。

根据测试前期准备确定的测试工具需求可以发现,在目前市面上的商业工具中几乎没有工具可以完全满足这些需求,因此经过讨论,最终将测试工具的引入方式定位在“创建”上,即完全自行开发需要的测试工具。

对测试工具的需求再次进行分析和分解,从模拟设备程序、记录程序和压力工具3个方面来考虑,形成了本案例需要的工具列表,如表1、2所示。

表1

表2

多学两招:

从表1、2中可以看到,为了完成本案例的性能测试,在测试工具上的投入就需要花费33人天。实际上,测试结束后的统计表明,花费在工具设计和开发上的工作量远远高于这个数值,原因是该工具也需要进行反复的设计修改和开发修改,并需要通过测试验证工具的功能正确性。

与测试工具相关活动的资源投入,从测试结束后的统计数据中得到的数据是51人天,如果按照工作日22天/月来计算,相当于是2.3个人1月的投入。

细心的读者应该能注意到,上表的测试工具中,前两个工具都要求能够在Windows和UNIX平台上运行,之所以这样要求,是因为我们希望能够充分利用设备资源。

表中的“模拟设备”的前两个测试工具最终用Perl实现,这样可以方便实现跨平台;后一个测试工具用C语言实现,因为该工具对程序效率要求较高。

测试计划

测试计划阶段需要分析用户活动,确定系统的性能目标。

1、性能测试领域分析

根据对项目背景的了解,本性能测试要解决的主要问题问题包括:验证系统是否达到了预期的性能指标、验证系统是否能稳定运行、验证系统的失效恢复方案是否有效以及在测试过程中有针对性的进行部分调优工作,以保证系统能够达到预期的性能要求。

这些内容涵盖了第2章中给出的能力验证、性能调优两个应用领域。进一步根据第2章的内容,本测试可用的性能测试方法为除ConcurrencyTesting外的其他性能测试方法。

2、用户活动剖析与业务建模

在本案例中,用户活动主要通过话务交换机的行为来体现,因此,本活动的主要内容集中在为应用建模上。

通过对话务交换机的行为进行抽象,可以得到一个简化的话务交换机模型。就本案例关注的交换机功能,简化后的话务交换机模型如图2所示。

图2

对本案例的业务系统来说,交换机可以简化成具有3个端口的设备,这3个端口分别是话务口、告警口和操作口。

(1)话务口

话务口可被看作一个TCP/IP端口,该端口等待连接,在给定的话务周期到达时,向所有连接在该端口上的连接发送话务报告,话务报告以二进制数据流方式发送,不同交换机的话务报告格式和数据量均不不同。

(2)告警口

告警口可被看作一个TCP/IP端口,该端口等待连接,在交换机内部发生故障或错误时,向所有连接在该端口上的连接发送告警报告,告警报告以二进制数据流方式发送,不同交换机的告警报告格式和数量均不同。

(3)操作口

操作口可被看作一个向其发送具有一定格TCP/IP端口,该端口等待连接,连接上该端口的连接可以式的命令,当命令格式正确时,交换机执行命令请求的操作并以二进制数据流方式返回结果。

因为这3个端口之间没有直接的关联,因此,采用表1描述的测试工具可以完全模拟图2给出的话务交换机简化模型。

对本案例而言,需要进行性能测试的业务系统需要连接这3种不同的端口,并对下发和接收到的数据进行处理,业务系统的处理方式有以下4种。

(1)话务报告处理

话务报告处理过程从系统接收到话务数据流开始,接收到数据后先进行初步分析(分离报告),将报告形成文本文件保存在本地,同时向消息队列中发送一个消息。

分析进程阻塞消息队列,当在消息队列中发现消息后就取出该消息并按照消息指示对本地文件进行处理。对本地文件的处理是从文件中分析出数据并写入数据表的相应字段。

该业务系统的话务报告处理过程如图3所示。

图3

(2)告警报告处理

告警报告的处理过程从系统接收到告警数据流开始,在该业务系统中,告警数据直接由HP的Temip平台进行处理,告警数据流直接发送给Temip平台。通过一个入库进程,告警数据在处理后进入数据库。告警报告的处理过程如图4所示。

图4

(3)用户操作处理

用户操作的处理过程从用户下发交换机命令开始,用户通过一个被称为“仿真终端”的应用向交换机发送命令,通过一个连接交换机代理程序将命令排队处理后发送给交换机。用户操作的处理过程如图5所示。

图5

(4)其他业务系统操作处理

其他业务系统的操作处理从其他业务系统发送消息开始,通过一个业务接口程序,将其他业务系统发送的消息分析形成交换机命令,通过连接交换机的代理程序将命令排入命令队列进行处理,如图6所示。

图6

多学两招:

分析应用的行为对于这种类型的应用非常重要,不深入了解应用系统的实现方式,就不可能明确知道性能测试时究竟应该关注哪些内容。对于大部分属于用户交互的应用来说(如OA系统),往往只需要考虑用户的感觉(也就是用户感受到的响应时间),对性能测试条件的分析也集中在对用户行为的分析上;而对于本案例描述的这些应用(银行的某些业务系统也是典型的此类应用),对性能测试条件的分析就需要明确知道应用的工作方式,这样才能明确在性能测试中需要关注哪些内容。

分析应用行为的最好方法是用流程图的形式描绘出业务系统中涉及的各进程和数据交互过程,由此可以清晰地得到性能测试中需要关注的内容。

3.确定性能目标

本性能测试的应用领域已被确定为能力验证和性能调优,因此在确定性能目标时,应该围绕这两个方面进行。

本项目是一个开发项目,需求和设计中已经对部分性能目标进行了定义。在本案例中,从需求和设计中得到的与性能相关的描述包括。

(1)系统能够及时处理完全省交换机的话务数据。

(2)系统能够处理平均值为300次/秒的告警,能够承受峰值为600次/秒的告警。

(3)系统能够快速响应用户下发的命令。

(4)系统能够及时处理其他业务系统发送的交换机操作消息。

(5)系统能够稳定运行。

(6)系统能够在一台采集服务器、一台应用服务器和一台数据库服务器由于特殊原因崩溃时不间断运行。

在这些描述中,除了第(1)、(2)、(6)条是比较清晰的性能需求描述外,其他3条都是非明确的性能需求。而且,即使是第(1)、(2)条,也同样需要进一步的确认。为此,在该活动中,性能测试组通过与项目经理和客户的多次沟通,对性能测试需求进行了更加明确的确认。

(1)系统能够及时处理完全省交换机的话务数据:该业务系统接入的全省话务交换机数量为600台,其中约20%的交换机话务周期设置为15分钟,这部分交换机的话务报告平均大小约为4KB;约有30%的交换机话务周期设置为30分钟,这部分交换机的话务报告平均大小约为6KB;约50%的交换机话务周期设置为1小时,这部分交换机的话务报告平均大小为7KB。

(2)系统能够处理平均值为300次/秒的告警,能够承受峰值为600次/秒的告警:该业务系统接入的交换机数量为600台,300次/秒的告警发生频率相当于每台交换机每秒发生0.5次告警,考虑到各交换机具有不同的告警发生频率,经过对现网运行系统一周数据的分析表明,发生告警最多的设备大约每秒发生2次,发生告警最少的设备大约每小时发生2次,差别巨大。并且,用户实际还有一个并未在需求文档中给出的隐含要求:告警从产生到呈现的时间延迟小于5秒。

(3)系统能够快速响应用户下发的命令:经过与用户的确定,“快速”被重新定义为用户下发命令与在没有命令排队的情况下,交换机接收到命令的延时不得大于2秒,交换机反馈信息与用户接收到反馈信息的延时不得大于2秒。而且,明确的并发用户数量为100名。

(4)系统能够及时处理其他业务系统发送的交换机操作消息:经过与用户的沟通,用户对该业务系统的要求实际上是系统不能丢失其他业务系统发送的交换机操作消息,因此该需求实际描述的是系统的命令缓存能力,最终该需求被描述为:系统能够缓存1000条其他业务系统发送的消息不再接受新的消息并返回给发送消息的业务系统一个错误信息,当缓存区满时,。经过这样的分析,该需求变成了一个功能的需求,不再需要在功能测试中体现。

(5)系统能够稳定运行:该需求最终被表述成系统在压力下的性能表现,根据其他可参考的系统稳定性依据,该需求被描述为系统能够在比稳定运行时大2倍的压力条件下持续运行14天,期间各应用进程占用的内存及应用响应速度都不会发生明显变化。

(6)系统能够在一台采集服务器、一台应用服务器和一台数据库服务器由于特殊原因崩溃时不间断运行:对该需求的一个补充是,由服务器失效引发的切换必然会使正在进行的业务收到影响,因此,允许切换过程中产生不完整的数据。另外,应用的切换必然存在一个切换时间,商定的允许切换时间为5分钟。

指点迷津:

需求文档、设计文档以及其他相关文档中给出的性能需求通常都会存在含混不清的地方,在设计性能测试之前,必须将这些地方彻底理清。甚至在某些情况下,不同来源的文档之间会存在冲突,这时应该向项目经理说明此事,并由客户代表进行最终的决定,决定后的结果需要明确记录下来。

表3给出了分析整理后的性能需求描述。

表3

对能力验证应用领域来说,本测试需要重点关注的是业务的响应时间、各服务器的资源使用状况,结合性能测试需求,性能目标可以定义如下:

  • 在满足全省话务数据规模的情况下,服务器CPU平均使用率不高于75%,内存使用率不高于75%。
  • 在平均告警规模下,服务器CPU平均使用率不高于75%,内存使用率不高于75%;峰值情况下,服务器CPU平均使用率不高于90%,内存使用率不高于85%。
  • 没有命令排队情况下,交换机接收到命令的延时小于2秒,用户接收到反馈信息的延时小于2秒。
  • 各组单台设备故障时,系统切换时间不大于5分钟,切换后业务如常进行。

对性能调优应用领域来说,本测试关注的重点是通过各种设置和部署的调整(原则是:除非确定是应用问题,否则优先考虑调整设置和部署方法),使系统性能表现能够达到预期的要求。

指点迷津:

对上线的应用系统来说,影响其性能表现的因素很多,我们建议的调优顺序是优先考虑系统级的调优,例如对应用服务器设置的调优、数据库设置的调优和应用部署方式的调优。只有在确认是应用的问题,或是其他调优方法都不能奏效时,才考虑对应用代码进行调优。

根据笔者的性能测试项目经历,将近60%的应用系统性能问题都可以通过调整应用服务器设置、调整部署或调整数据库设置获得良好的性能提升,只有少数情况不得不对代码进行调优。

4.制定测试时间计划

本案例的特点之一在于测试中使用的大部分测试工具都是自行开发的,因此必须留出较多的时间进行工具的设计和开发。另外,由于系统本身的复杂性,测试环境构建也需要一定的时间。本案例的测试时间计划安排如表4、5所示。

表4

表5

注:①在本案例的前期己经对工具开发的工作量进行了估算,估算得到的数值是33人天,此处的时间安排即是按照该估算进行的。

②这里用了一些虚拟的人名表示测试组成员。特别要提醒的是,在FailoverTesting过程中,一定要系统工程师和数据库工程师的参与并准备好应急方案,一旦测试过程中发生意外,要按照预先制定好的应急方案对系统进行恢复。

测试设计与开发

测试设计与开发包括测试环境设计、测试场景设计、测试用例设计和测试辅助工具开发多个活动。对类似本案例的业务系统而言,测试场景关注的主要内容不是用户感受,而是系统的业务处理能力,因此在测试场景设计上,注重的是通过何种方式获取和性能相关的数据及如何对获取的数据进行解释。

1.测试环境设计

本性能测试需要验证系统在实际生产部署环境上的性能,因此,尽可能选择接近实际生产环境的环境来进行测试。

该项目测试的一个特点是需要通过模拟手段来模拟实际的话务交换机设备,结合前文中建立的话务交换测试模型,和图1给出的系统示意图,最终确定的测试环境包括预计用于实际运行的全部服务器条件,通过工具模拟的话务交换机运行于中心机房的PC机和非测试用服务器上。

这个测试环境与实际环境之间唯一的差异在于:系统接入的话务交换机不是真正的设备。对本系统来说,可能存在以下风险:

(1)因为报告传输速度不同,可能导致测试结果上出现不同。

(2)实际设备可能发出不完整报告,而模拟的设备不会,两者之间存在的差异可能导致性能测试的结果不正确。

当然,这两个风险在一定条件下可以解决,在本案例中,通过约束和分析解决了这两个风险:对第1个风险,根据对各不同地市的不同机型交换机传输速度的调查,最慢的交换机(通过MOXA转接方式)也可以在2分钟内完成所有报告的传输,而且这些慢速传输的交换机的话务报告周期都设置为1小时;对第2个风险,实际设备发出的不完整报告会被接入进程丢弃,在性能测试过程中只要能验证不完整报告不会对接入进行的性能造成显著影响即可。

指点迷津:

使用非生产环境作为测试环境进行性能测试时,最好对环境之间的差异进行详细分析并评估由此带来的风险,在测试计划中需要明确说明风险的解决方法或相应的对策。

该性能测试的另一个应用领域是性能调优,因此在性能测试过程中,需要合理且合适的测试环境维护方法,保证在调优的测试过程中测试环境能够保持可信的基准。最终确定了5个测试环境,如6、7所示。

表6

表7

本案例中的测试数据环境设计根据系统的运行预期来确定。该系统的数据备份清除原则是:系统数据每3个月进行一次备份和清除操作,每次清除操作将数据库中两个月以前的业务数据全部清除。

从以上的描述可以看出,系统在稳定运行后,数据库中的业务数据至多保留3个月,最少两个月,为了考察性能表现,我们以3个月的业务数据作为数据库中数据的基准。

采用类似第一个案例的计算方法,计算得出的数据库中历史数据环境如下:

话务数据表:19440000条记录。

告警数据表:2120000条记录。

为了保证数据环境在每次测试中保持一致,首次生成数据记录后,将数据库输入(export)为本地文件并保存,在每次测试开始前,都通过输入(import)方法将数据直接导入到数据库,保证数据环境的一致。

另一方面,由于本性能测试使用的测试工具多且分散,在实际测试中将工具的启动形成shell脚本或是bat文件,以具有意义的名称进行管理。

另一个需要设计的是时间同步方案。本案例中需要记录的测试结果数据很多,部分数据的处理需要根据记录时的时间进行,而根据测试环境,应用部署较为分散,因此有必要为整个测试环境设计一个时间同步方案,以使整个测试环境中的各台设备具有精确一致的时间。

本案例涉及的是一个UNIX和Windows的混合环境,因此采用ntp协议进行各设备之间的时间同步。

2.测试场景设计

根据表2、3,可以很容易地为该案例给出需要的测试场景,如表8、9所示,其中每个场景对应一个测试需求。

表8

表9

由表8、9看出,只要按照场景名称、场景业务及比例分配、测试指标、性能计数器的描述方式,就可以非常清晰地对场景进行描述。

3.测试用例设计

确定测试场景之后,在原有的业务操作描述上,可以更进一步完善为可映射为脚本的测试用例描述。如果测试过程中需要较多的辅助工具进行协作,在用例设计中可能还需要描述工具部署情况。

在本案例中,用例设计的主要考虑内容是如何获得与系统性能相关的数据,因此在本案例的测试用例设计描述过程中,我们设计了6个对应测试场景的方案。方案采用测试模型、测试说明、测试用例概述的方式进行描述。

(1)方案1——对应场景。测试系统能否及时处理完全省交换机的话务数据,测试模型如图7所示。

图7

①测试过程中采用600个模拟交换机设备发送话务数据,120个模拟的5ESS设备,话务周期为15分钟,话务报告为4KB;180个模拟的Siemens设备,话务周期为30分钟,话务报告为6KB;300个模拟的Ericsson设备,话务周期为1小时,话务报告为8KB;600个模拟设备的进程分布在15台测试机上,每台测试机运行40个模拟设备的进程。

②测试过程中,采用3台采集机,每台采集机上运行一个接入进程和6个处理入库进程。之所以用6个处理入库进程,是因为采集服务器设备有6个CPU,6个进程可以最大限度地提高处理效率。

③为了记录话务数据处理过程中的各个时间点(模型中的T1、T2、T3标识),约定如下:

  • 在模拟设备程序目录下的sendlog.log文件记录发送出话务数据的时间戳和局号。
  • 接入程序的日志记录该程序发送的消息等内容,文件存放在采集服务器的/opt/mytest/data/目录下。
  • 分析入库程序的日志位于采集服务器的/opt/mytest/log/plog目录下。该程序的日志内容包含接收消息的时间、处理的时间以及数据入库时间。

【验证方法】

以最后一个报告已入库的时间作为全部报告的入库结束时间,该时间提前于下一话务周期。

(2)方案2—对应场景:测试系统能否处理平均值为300次/秒的告警,测试模型如图8所示。

图8

①每个模拟设备进程等待1~20秒的随机时间,发送5条告警,总的告警频度为600×5/10=300次/秒,告警持续发送8小时。之所以采用随机等待的方式,是为了更好地模拟真实的生产环境,使测试结果具有更大的可信度。

②模拟设备进程发送的告警附带的告警发生时间是运行模拟设备进程的机器当前时间,检查告警是否在5秒内呈现的方法是在告警呈现应用(PC应用)上直接查看告警的发送时间和实际呈现的时间,比较时间差。

【验证方法】

通过对比已发送告警和界面上呈现告警、数据库中的数据来核对数据的准确性,包括:界面呈现告警和实际发送告警的数量、类型是否一致;数据库中入库的告警数据与界面呈现告警是否一致。

(3)方案3——对应场景:测试系统能否处理峰值为600次/秒的告警,其测试模型与方案2相同。

①600个模拟设备进程中,200个进程每秒发送2条告警,400个进程随机等待0~4秒,发送1条告警,总的告警频度为200×2+0.5×400=600次/秒,告警持续发送1小时。

②模拟设备进程发送的告警附带的告警发生时间是运行模拟设备进程的机器当前时间,检查告警是否在8秒内呈现的方法是在告警呈现应用(PC应用)上直接查看告警的发送时间和实际呈现的时间,比较时间差。

【验证方法】

通过对比已发送告警和界面上呈现告警、数据库中的数据来核对数据的准确性,包括:界面呈现告警和实际发送告警的数量、类型是否一致;数据库中入库的告警数据与界面呈现告警是否一致。

指点迷津:

在方案2和方案3中,检查告警是否在规定时间内呈现的方法是在告警呈现应用(PC应用)上直接查看告警的发送时间和实际呈现的时间,比较时间差。但设想一下,在实际操作中,当用户界面上以每秒300或600次的频率呈现告警时,要计算出每条告警的实际呈现时间几乎不可能。

此时可以采用一种被称为“探针”(Probe)的技术,其原理是:将负载和实际观察数据分开,选用特殊的便于识别的数据作观察用。具体在本案例中,可视方案中设定的告警产生为负载,为了知道告警是否在指定时间内得到呈现,在负载之外用一个特殊的模拟设备进程发出特殊的告警,在告警呈现应用中仅计算该特殊告警的呈现时间。

(4)方案4——对应场景:测试系统能否快速响应用户下发的命令,测试模型如图8.9所示,其逻辑简化图如图9、10所示。

图9

图10

该模型用于测试命令下发和命令结果回显,根据测试用例的描述,在测试中需要记录时间点T1、T2、T3、T4。

①模拟200个话务交换机设备,模拟程序能接收用户下发的交换机命令perftest、lgi并发送回应。

②用模拟程序SimTerm模拟200个终端连接设备,充当负载。该模拟程序以每分钟一条命令的频率发送perftest命令。

③实际运行一个命令终端应用,在该应用进程中由用户手工输入命令,程序记录下用户输入命令时间等关键时间点。

④为了记录时间T1、T2、T3、T4,有以下约定:

  • SimTerm发送的命令附带发送时的时间戳,一个典型的命令格式为:perftest:2004-09-2015:23:00。
  • 终端应用程序在发送命令时,附带一个用户输入命令结束的时间戳,一个典型的命令格式为:igi:2004-09-2015:23:00,这个时间就是我们定义的时间T3。
  • 交换机设备模拟程序记录接收到命令的时间T1,并从接收到的命令中分离出时间T3,记录T1、T3和T3-T1;交换机设备模拟模拟程序在发送回应的时候在回应的报文中附带发送时的时间戳(T2)。
  • 命令终端程序接收交换机设备模拟程序发送的回应报文,分离并记录出其中的时间T2、记录报文回显完成的时间T4,并计算T4-T2。

⑤持续测试1小时,

TAG:

 

评分:0

我来说两句

日历

« 2021-11-28  
 123456
78910111213
14151617181920
21222324252627
282930    

我的存档

数据统计

  • 访问量: 1137
  • 日志数: 5
  • 建立时间: 2017-10-20
  • 更新时间: 2017-10-20

RSS订阅

Open Toolbar