RYU控制器性能测试报告
LoadRunner性能测试指标参考
性能测试指标参考目录1术语 (2)1.1响应时间 (2)1.2并发用户数 (2)1.3在线用户数 (2)1.4吞吐量 (3)2 Vuser图 (3)2.1 “运行Vuser ”图（Running Vusers） (3)2.2 “集合”图(Rendezvous) (3)3 错误图 (3)3.1 “每秒错误数（按描述）”图（Error Statistics） (3)4 事务图 (4)4.1 “平均事务响应时间”图（Average Transaction Response Time） (4)4.2“负载下的事务响应时间”图（Running Vuser –Average Transaction Response Time） (4)4.3“页面细分”图（Web Page Diagnostics图） (5)4.4“每秒事务数”（Transactions per second 简称：TPS） (6)5 Web资源图 (6)5.1“每秒点击次数”图（Hits per Second） (6)5.2“吞吐量”图（Throughput） (6)6 系统资源图 (6)6.1 LoadRunner下监控的UNIX资源指标 (6)6.1.1平均负载（Average load） (6)6.1.2 CPU利用率（CPU utilization） (7)6.1.3 每秒传入的包数（Paging rate） (7)6.2使用NMON工具监控Linux资源 (7)6.2.1 系统资源汇总（SYS_SUMM） (7)6.2.2 磁盘资源汇总（DISK_SUMM） (8)6.2.3 内存资源（MEM） (8)7 网络监控器图 (9)7.1 “网络延迟时间”图（Network Delay Time） (9)8 数据库服务器资源图 (10)8.1 Oracle服务器监控度量 (10)8.1.1 添加Oracle自定义计数器 (11)8.1.2 性能分析工具Statspack所提供的性能分析指标 (15)8.2 SQL Server服务器监控度量 (18)1术语1.1响应时间响应时间是从请求到响应所需时间，从客户端请求开始，结束于来自服务器的响应并呈现页面的时间。
性能测试报告模板_LoadRunner性能测试系统学习教程：Analysis分析器（4）
性能测试报告模板_LoadRunner性能测试系统学习教程：Analysis分析器（4）上期讲到LoadRunner性能测试Analysis分析器的Analysis常见图分析，这期我们来讲讲，Analysis报告。
Analysis报告场景运⾏结束后，可以在Analysis分析器中⽣成报告。
Analysis分析器提供了丰富的报告形式：HTML格式、SLA报告、⾃动定义报告和使⽤报告模板来定义报告。
HTML报告使⽤Analysis可以为⽅案运⾏创建HTML报告，如图所⽰。
保存的HTML报告包括在Analysis窗⼝打开的所有图和⼀个摘要报告。
这个摘要报告与Analysis窗⼝中看到的摘要报告内容相同。
⽽其他的视图报告数据则都来⾃于Excel⽂件的链接。
Excel⽂件保存在⽣成HTML报告时⽣成的Report⽂件夹下。
在创建HTML报告时，会同时⽣成⼀个Report⽂件夹，Excel⽂件链接的数据就来⾃这⾥。
SLA报告如果在分析器或控制器中设置了SLA策略，那么LoadRunner可以⽣成SLA的相关报告，选择菜单Report→Analyze SLA，分析器会⽣成SLA的结果报告如图所⽰。
SLA结果报告中包含两部分内容：第⼀部分是事务响应时间，SLA会标⽰出在分析的时间域中每个事务的SLA结果状态，如果表⽰为PASS 说明事务响应时间没有超过SLA所定义的阀值，如果为FAIL说明事务响应时间超出SLA所定义的阀值；第⼆部分是每个事务所定义的⽬标阀值。
⾃定义报告选择Report→New Report，弹出New Report对话框，如图所⽰。
通过该对话框可以设置需要⽣成的报告。
新报告对话框中包括三个选项卡的设置：General、Format和Content。
General选项卡主要是设置⼀些通常⽤的信息，主要包括以下信息：Title：描述报告的名称；Author：描述作者的相关信息，包括First Name、Surname、Job Title和Organization。
LOADRUNNER稳定性测试报告
LOADRUNNER 稳定性测试报告200人稳定性测试报告,1 测试概要 ..................................................................... ........... 3 1.1 测试目的 ..................................................................... ..... 3 1.2 环境部署 ..................................................................... ..... 3 1.3 场景描述 ..................................................................... ..... 3 1.4 LoadRunner场景 (4)1.5 场景设置 ..................................................................... ..... 4 1.6 最耗时的事务 .....................................................................4 2 测试结果 ..................................................................... ........... 4 2.1 用户加载: .................................................................... .... 5 2.2 平均事务响应时间: ............................................................. 5 2.3吞吐量 ..................................................................... ........ 6 2.4 处理事务总数 .....................................................................6 2.5 点击率 ..................................................................... ........ 7 3 测试总结 ..................................................................... ........... 7 ,,,,,,,,,,,,,,1.1 测试目的,采用LoadRunner8.0工具，模拟200个用户，验证产品的稳定性状况以及服务器资源的利用情况。
Ryu控制器简介
Ryu控制器简介Ryu是一款开源SDN 控制器，完全由Python 语言实现，使用者可以用Python 语言在其上实现自己的应用。
Ryu 目前支持所有版本的Openflow协议。
Ryu架构图：Ryu代码结构：▪App在RYU控制器上面运行的应用，基于控制器完成特定的功能。
▪basebase中有一个非常重要的文件：app_manager.py，其作用是RYU应用的管理中心。
用于加载RYU应用程序，接受从APP发送过来的信息，同时也完成消息的路由。
其主要的函数有app注册、注销、查找、并定义了RYUAPP基类，定义了RYUAPP的基本属性。
包含name, threads, events, event_handlers和observers等成员，以及对应的许多基本函数。
如：start(), stop()等。
这个文件中还定义了AppManager基类，用于管理APP。
定义了加载APP等函数。
不过如果仅仅是开发APP的话，这个类可以不必关心。
▪controllercontroller文件夹中许多非常重要的文件，如events.py, ofp_handler.py, controller.py等。
其中controller.py中定义了OpenFlowController基类。
用于定义OpenFlow的控制器，用于处理交换机和控制器的连接等事件，同时还可以产生事件和路由事件。
其事件系统的定义，可以查看events.py和ofp_events.py。
在ofp_handler.py中定义了基本的handler，完成了基本的如：握手，错误信息处理和keep alive 等功能。
更多的如packet_in_handler应该在app中定义。
在dpset.py文件中，定义了交换机端的一些消息，如端口状态信息等，用于描述和操作交换机。
如添加端口，删除端口等操作。
▪liblib中定义了我们需要使用到的基本的数据结构，如dpid, mac和ip等数据结构。
LOADRUNNER稳定性测试报告
LOADRUNNER稳定性测试报告1.引言稳定性测试是软件开发过程中非常重要的一环，它能够评估系统在长时间高负载条件下的表现，发现潜在的性能问题，并为性能优化提供依据。
本报告通过使用LOADRUNNER进行稳定性测试，对系统的稳定性进行评估，并提供相关测试结果和分析。
2.测试目标本次稳定性测试的目标是评估系统在长时间高负载情况下的性能表现，并寻找系统可能存在的潜在性能问题。
3.测试环境- 系统环境：Windows Server 2024-软件版本：LOADRUNNER12.5- 测试工具：LOADRUNNER Controller和LOADRUNNER Agent4.测试过程4.1准备阶段在测试之前，我们首先对系统进行了性能需求分析，并确定了测试场景、用户行为脚本和负载模型。
同时，我们对系统和测试环境进行了配置和准备，包括安装LOADRUNNER软件、配置测试环境、准备测试数据等。
4.2测试步骤我们按照预先确定的测试场景和负载模型，使用LOADRUNNER Controller进行测试。
测试期间，我们监控系统的性能指标，并记录关键数据，如响应时间、吞吐量和错误率等。
4.3结果分析执行稳定性测试后，我们对测试结果进行了整理和分析。
通过对比不同负载下的性能指标，我们可以评估系统在高负载情况下的可靠性和稳定性，并发现潜在的性能瓶颈和问题。
5.测试结果5.1响应时间在测试期间，我们记录了系统的平均响应时间，并根据负载情况绘制了相应的图表。
从结果可以看出，随着负载增加，系统的响应时间逐渐增加。
但整体来说，系统的响应时间在可接受的范围内，并没有出现明显的性能问题。
5.2吞吐量我们还记录了系统的吞吐量，即每秒钟处理的请求数量。
通过对比不同负载下的吞吐量，我们可以评估系统的处理能力。
测试结果显示，系统在高负载情况下的吞吐量仍然维持在较高的水平，没有出现明显的性能下降。
5.3错误率我们还跟踪了系统的错误率，即请求失败或出错的比例。
loadrunner案例性能测试报告
目录1引言 (2)1.1目的 (2)1.2使用对象 (2)1.3术语表 (2)2测试环境 (3)2.1网络拓扑 (3)2.2硬件配置 (3)2.3软件配置 (4)2.4基准参数配置 (4)3测试范围 (4)4测试工具 (5)5测试结果 (5)5.1 B/S登陆 (5)5.1.1分析图 (6)5.1.2结果分析 (7)5.2 C/S登录 (8)5.2.1分析图 (8)5.2.2 结果分析 (9)5.3 策略下发 (9)5.3.1 分析图 (10)5.3.2 结果分析 (11)5.4 策略下发+C/S登录+B/S登录 (11)5.4.1分析图 (12)5.4.2结果分析 (13)6分析总结 (13)7 附录 (15)7.1测试指标说明 (15)1引言1.1目的由于德邦项目在V3.8的基础上根据用户需求做了改动，此次测试目的主要是针对德邦项目进行性能的能力验证和性能的规划，同时为开发提供性能测试数据，明确性能瓶颈和缺陷。
1.2使用对象本文档提供给产品管理人员、公司领导、项目中的测试及开发人员，属公司项目内部文档，。
1.3术语表2测试环境2.1网络拓扑2.2硬件配置测试硬件设备及配置明细描述如下表：2.3软件配置2.4基准参数配置1)Oracle：内存：SGA总容量：100M ; PGA大小：194M ;Max Process:500；session：550注：PGA和SGA的和应小于系统内存总量减去操作系统和其他应用程序所需内存后得到的值。
2)Tomcat：<Connector port="80" protocol="HTTP/1.1" maxThreads="1024" connectionTimeout="300000" maxProcessors="512" enableLookups="false" acceptCount="1024" debug="0"useURIValidationHack="false" disableUploadTimeout="true" redirectPort="8443" /><Connector port="8443" className="org.apache.coyote.http11.Http11Protocol"maxThreads="1024" minSpareThreads="200" maxSpareThreads="512" enableLookups="false" disableUploadTimeout="true" acceptCount="1024" scheme="https" secure="true" SSLEnabled="true" clientAuth="false" keystoreFile="conf/esafenet.key" keystorePass="esafenet" sslProtocol="TLS" />3)JVM:-Xms256M –Xmx512M4)应用程序：Common.cfg.xml(数据库连接池)：max_size：60 min_size：120（操作系统保持干净，没有任何其他干扰程序，如杀毒，防火墙等）3测试范围1）单场景：B/S登录、C/S登录、策略下发3个关键场景2）最佳测试记录组合场景：策略下发+C/S登录+B/S登录4测试工具1）MI（MercuryInteractive）公司的LoadRunner8.0创建虚拟用户脚本工具Virtual User Generator。
电动车控制器测试报告(共)(两篇)2024
引言概述：电动车控制器作为电动车的重要组成部分，起着控制车辆速度和功率的关键作用。
因此，对电动车控制器进行测试和评估至关重要。
本文将对电动车控制器的性能、功能、安全性等方面进行详细分析和测试，以提供准确的测试报告。
正文内容：1. 控制器性能测试1.1 额定功率测试额定功率是电动车控制器的重要性能指标，通过测试控制器在额定功率下的输出能力，可以评估其性能和稳定性。
测试过程中可以采用负载，并在不同负载情况下测量控制器的输出功率和效率。
1.2 车速控制精度测试车速控制是电动车控制器的主要功能之一，测试控制器在不同速度下的控制精度，可以评估其对车速的准确控制能力。
测试过程中可以使用速度传感器进行实时测量，比较测得的车速和控制器设定的目标车速之间的差异，以评估其控制精度。
1.3 响应时间测试响应时间是评估电动车控制器性能的重要指标之一，测试控制器对输入信号的反应时间，可以评估其对车辆驾驶员操作的即时响应能力。
测试过程中可以模拟不同驾驶操作，记录响应时间并进行分析和评估。
2. 控制器功能测试2.1 车辆启动与停止功能测试该功能测试包括测试电动车控制器对车辆启动和停止的控制能力。
测试过程中可以模拟车辆启动和停止的操作，并记录控制器的输出信号和车辆的实际响应情况，以评估其功能的准确性和可靠性。
2.2 制动能量回收功能测试制动能量回收是目前电动车控制器的一项重要功能，测试控制器对制动能量的回收和储存能力。
测试过程中可以模拟制动操作，并测量回收的能量和储存的能量，以评估其回收的效率和容量。
2.3 过流保护功能测试过流保护是电动车控制器的一项关键保护功能，测试控制器对过流情况的检测和保护能力。
测试过程中可以模拟过流情况，观察控制器的反应和保护机制的启动，以评估其过流保护的准确性和可靠性。
3. 控制器安全性测试3.1 短路保护功能测试短路保护是电动车控制器的一项重要安全功能，测试控制器对短路情况的检测和保护能力。
测试过程中可以模拟短路情况，观察控制器的反应和保护机制的启动，以评估其短路保护的准确性和可靠性。
实验6：开源控制器实践——RYU
实验6：开源控制器实践——RYU⼀、实验⽬的能够独⽴部署RYU控制器；能够理解RYU控制器实现软件定义的集线器原理；能够理解RYU控制器实现软件定义的交换机原理。
⼆、实验环境下载虚拟机软件Oracle VisualBox或VMware；在虚拟机中安装Ubuntu 20.04 Desktop amd64，并完整安装Mininet；三、实验要求（⼀）基本要求1、完成Ryu控制器的安装。
在Ryu安装⽬录下执⾏ryu --version查看版本2、搭建下图所⽰SDN拓扑，协议使⽤Open Flow 1.0，并连接Ryu控制器。
搭建拓扑：sudo mn --topo=single,3 --mac --controller=remote,ip=127.0.0.1,port=6633 --switch ovsk,protocols=OpenFlow10启动并连接ryu控制器：ryu-manager ryu/ryu/app/gui_topology/gui_topology.py --observe-links4、阅读Ryu⽂档的The First Application⼀节，运⾏并使⽤ tcpdump 验证L2Switch，分析和POX的Hub模块有何不同。
新建⼀个⽂件，编辑保存为 L2Switch.py ⽂件from ryu.base import app_managerfrom ryu.controller import ofp_eventfrom ryu.controller.handler import MAIN_DISPATCHERfrom ryu.controller.handler import set_ev_clsfrom ryu.ofproto import ofproto_v1_0class L2Switch(app_manager.RyuApp):OFP_VERSIONS = [ofproto_v1_0.OFP_VERSION]def __init__(self, *args, **kwargs):super(L2Switch, self).__init__(*args, **kwargs)@set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)def packet_in_handler(self, ev):msg = ev.msgdp = msg.datapathofp = dp.ofprotoofp_parser = dp.ofproto_parseractions = [ofp_parser.OFPActionOutput(ofp.OFPP_FLOOD)]data = Noneif msg.buffer_id == ofp.OFP_NO_BUFFER:data = msg.dataout = ofp_parser.OFPPacketOut(datapath=dp, buffer_id=msg.buffer_id, in_port=msg.in_port,actions=actions, data = data)dp.send_msg(out)使⽤命令ryu-manager L2Switch.py运⾏并验证（运⾏后再搭拓扑）：h1 ping h2h1 ping h3由上述结果可知，与POX的Hub模块相⽐，L2Switch的相同之处在于：Hub和L2Switch实现的都是洪泛发送ICMP报⽂，所以在h2和h3可以看到都有抓到数据包。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
RYU控制器性能测试报告全球SDN测试认证中心SDNCTC2016．3．8一、引言当软件定义网络（Software Defined Network, SDN）逐渐成为网络世界新的范式，转发与控制的分离使得数据平面只作为单纯的数据收发引擎，而控制平面则承担了全部的逻辑与运算任务。
作为控制平面的核心组件，SDN控制器的性能关乎整个SDN网络的性能表现。
随着SDN商业部署速度地加快，SDN控制器性能也必将越来越多地成为网络用户关心的焦点。
OFsuite_performance是全球SDN测试认证中心（SDNCTC）独立开发的OFsuite系列测试工具之一，此测试工具致力于OpenFlow 控制器性能测试。
能够在通用Linux服务器上模拟大量OpenFlow 1.3交换机，并且能够模拟不同的网络拓扑以及全部的OpenFlow事件。
该测试工具能够在真实的SDN网络环境中运行，从而有效地衡量控制器对OpenFlow消息的处理能力。
其测试结果能够在网络用户进行SDN网络性能评估，测试及商业部署时提供可靠的数据支撑。
除此之外，还可以提供多控制器连接，TLS加密通道连接，测试结果可视化等附加功能。
该测试工具简洁、高效、易于使用，并将持续更新以便为用户提供更丰富的性能测试案例及测试场景。
本报告以开源控制器RYU作为被测控制器，使用OFsuite_performance执行测试，汇总结果得出性能测试报告。
全部测试例均为OFsuite_performance自动化测试完成，报告中所展示的结果图表均为测试工具自动生成。
二、测试环境配置2.1 待测控制器待测控制器为目下流行的开源控制器RYU，版本为v3.28，该版本的RYU控制器完全支持OpenFlowv1.3南向协议。
2.2 服务器配置待测控制器RYU运行于一台单独的服务器上，其配置如下：•处理器：Intel(R) Xeon(R) E3-1230 @ 3.20GHz 4核•内存：8GB 1333MHz•操作系统：Ubuntu server 12.04 LTS 64位•网卡：1Gbps2.3 测试工具测试工具为OFsuite_performance，执行测试时，OFsuite_performance运行于一台与RYU控制器所在服务器直连的服务器上，服务器配置如下：•服务器型号：Dell PowerEdge R720•处理器：Intel(R) Xeon(R) E5-2609 v2 @ 2.50GHz 4核•内存：8GB 1600MHz•操作系统：Ubuntu server 14.04.1 LTS 64位•网卡：1Gbps三、测试项目及测试结果3.1 控制信道容量测试•测试目的测试控制器OpenFlow 1.3控制通道能够维持的最大连接数。
•测试方法1本测试中，测试工具模拟一定数量的OpenFlow 1.3交换机并连接到待测控制器，测试待测控制器所能维持的最大交换机数量，具体测试步骤如下：1.开启待测控制器并同时开启simple_switch_13应用；2.开启测试工具OFsuite_performance，使用“—switches=[N]”选项设定一定数量的OpenFlow1.3交换机连接到待测控制器；3.使用set-topo命令设置一种拓扑结构（支持预先定义的linear/ring/full-mesh/leaf-spine结构，也可自定义拓扑结构），待连接稳定后记录控制器的内存占用情况；4.使用add-sw命令增加交换机数量并待连接稳定后记录控制器的内存占用情况；5.以不同的交换机数量和拓扑结构迭代执行测试，得到最终结果。
•测试工具要求1.测试工具可以模拟大量OpenFlow 1.3交换机，并与控制器建立连接；2.测试工具可以响应全部相关OpenFlow 1.3协议消息（Hello，Echo，feature_request, etc）；3.测试工具可以随时监测控制通道活性；4.测试工具可以灵活调整连接交换机数量；5.测试工具具有详尽的Log功能。
•测试结果1 全部测试例的详细测试拓扑及测试方法请参考全球SDN测试认证中心发布的《SDN控制器性能测试白皮书》在上述测试结果中可以看到，在相同网络拓扑结构下，随着交换机数量的增加，控制器处理交换机各种请求时所占用的系统内存资源也随之增加；另外，在相同交换机数量下，控制器处理不同复杂程度的网络拓扑结构所占用的系统内存资源也不同，拓扑结构越复杂，内存占用越高。
OFsuite_performance最多可支持模拟10K+数量的OpenFlow 1.3交换机与控制器建立连接。
在本例中，当交换机数量超过1K时，被测控制器即出现通道连接断开，Feature Request消息不发送等问题，故不作为有效结果计入统计。
3.2 拓扑发现时间测试•测试目的测试控制器对不同交换机数量、不同类型的拓扑结构发现时间。
•测试方法本测试中，测试工具将模拟一定数量的交换机，并且交换机之间互相连接形成一定的网络拓扑结构，测试待测控制器完全发现此拓扑结构所用的时间，具体测试步骤如下：1.启动待测控制器；2.启动测试工具，启动时只设置交换机数量而不设置拓扑结构；3.待交换机与控制器的连接稳定后使用set-topo命令设定拓扑结构；4.测试工具记录控制器下发的第一个LLDP消息的时间，并依照流表内容响应该消息；5.测试工具记录最后一条LLDP消息上送控制器的时间；6.使用show-result命令查看测试结果；7.改变交换机数量并设置相同的拓扑结构进行迭代测试；8.不改变交换机数量但改变拓扑结构进行迭代测试；9.反复进行测试以得到平均测试结果。
•测试工具要求1.测试工具可以模拟大量OpenFlow 1.3交换机，并与控制器建立连接；2.测试工具可以响应全部相关OpenFlow 1.3协议消息（Hello，Echo，feature_request etc）；3.测试工具可以随时监测控制通道活性；4.测试工具可以创建不同的网络拓扑结构；5.测试工具可以解析Packet_out消息，以便提取其中的LLDP消息；6.测试工具可以解析LLDP拓扑发现消息，以便给出对应的响应；7.测试工具具有详尽的Log功能。
•测试结果从上图测试结果中可以看到，相同网络拓扑结构下，交换机数量越多，待测控制器完成拓扑发现所用的时间越长；而相同的交换机数量下，网络拓扑结构复杂程度不同，控制器完成拓扑发现所用的时间也不同，网络拓扑结构越复杂，拓扑发现所用的时间越高。
在图中显示的结果看来，Linear和Ring拓扑所需时间相似，而Leaf-spine拓扑所需时间则显著增加。
同时当交换机数量大于300时，RYU控制器不能有效完成Leaf-spine拓扑的发现过程。
3.3 PACKET_OUT下发速率测试•测试目的测试待测控制器下发Packet_out消息的时延和最大速率。
•测试方法本测试中，测试工具将模拟一个交换机连接到控制器，测试工具将以一定的速率恒速上发Packet_in消息，记录上发Packet_in消息的时间，Packet_in消息中包含了ARP_request请求，控制器收到此Packet_in后会下发Packet_out消息，测试工具收到待测控制器下发的Packet_out消息之后记录Packet_out的下发时间，通过所有的Packet_in和Packet_out记录计算待测控制器对Packet_in消息的响应速度(latency)以及Packet_out的下发速率(throughput)。
OFsuite_performance能够在低端服务器上达到每秒500K级的恒速Packet_in上发速率。
具体测试步骤如下：1.启动待测控制器；2.启动测试工具，设置一个交换机，不设置拓扑结构，等待交换机连接到控制器；3.在测试工具的命令行接口使用set-arp-rate命令设置交换机上发Packet_in的速率；4.等待测试工具完成测试；5.使用show-result命令查看测试结果；6.改变Packet_in上发的速率再次进行测试；7.反复进行迭代测试以得到平均测试结果。
•测试工具要求1.测试工具可以模拟OpenFlow 1.3交换机，并与控制器建立连接；2.测试工具可以响应全部相关OpenFlow1.3协议消息（Hello，Echo，feature_request etc）；3.测试工具可以上发包含ARP_request的Packet_in消息从而触发待测控制器下发Packet_out消息；4.测试工具可以自定义Packet_in消息Data field的内容；5.测试工具可以恒速上发Packet_in消息；6.测试工具可以解析Packet_out消息，以便确认该消息为对应Packet_in消息所触发；7.测试工具具有详尽的Log功能。
•测试结果在上图的测试结果中可以看到，当测试工具设置的Packet_in上发速率低于5000 packets/s时，待测控制器能够很好地处理上发的Packet_in消息，Packet_out下发的速度能够与Packet_in的速度保持一致，但是当Packet_in的速率大于5000 packets/s，例如6000 packets/s时，待测控制器已无法完全处理收到的Packet_in，下发Packet_out的速率也低于Packet_in的速率，由此看来，测试已达到被测控制器的最大Packet_out下发速率。
上图所示为待测控制器发送Packet_out消息的时延，此时间为测试工具上发Packet_in消息与控制器回发对应Packet_out消息之间的时延，从图上可以看到，随着Packet_in消息上发速度得增加，Packet_out消息的时延也越来越大。
详细的测试结果数据如下表所示。
Packet_in Rate Minimum latency (ms)Maximum latency(ms)Average latency (ms)10000.70996 1.85693 0.73175 20000.01807 8.448 0.60239 30000.35498 11.55786 0.51537 40000.63306 11.22705 0.96215000 1.83276 35.69214 6.26612 6000 4.44605 249.78613 137.53063.4 FLOW MOD下发速率测试•测试目的测试待测控制器下发流表的时延和最大速率。
•测试方法本测试中，测试工具将模拟一个交换机连接到控制器，测试工具将以一定的速率上发包含ARP_request的Packet_in消息，测试工具在收到待测控制器下发的Packet_out之后再上发包含对应ARP_reply的Packet_in消息，此时待测控制器会下发flow mod消息，然后根据Packet_in消息和flow mod消息的记录，计算待测控制器下发流表的时延和速率，具体测试步骤如下：1.启动待测控制器2.启动测试工具，设置一个交换机，不设置拓扑结构，等待交换机连接到控制器；3.在测试工具上使用set-arp-rate命令设置交换机上发packet in消息的速率；4.等待测试工具完成测试；5.使用show-result命令查看测试结果；6.改变Packet_in上发的速率再次进行测试；7.反复进行测试以得到平均测试结果。