谈谈如何有效的测量系统负载和响应

嵌入式系统在系统测试过程中往往需要进行 Stability, Robustness, Accessbility, Responsibility 等等系统测试. 以来保证系统的功能完整性和健壮性.

嵌入式系统在设计在立项阶段会给出一个设计目标, 比如一款路由器，往往会给出以下类似的要求:

• 支持 802.11n/g/a/b 支持.
• 支持 2.4G, 5G 双频.
• 最大速率支持 (450Mbps).
• …

作为系统设计者,需要在设计阶段锚定这些目标进行技术选型. 如果当前有类似产品设计经验, 可以借鉴之前的经验进行选型. 如果是第一次设计, 保守的做法便是借鉴其他厂商的方案, 等待自己对系统了解的加深和经验的丰富再进行下一阶段的开发.

无论以什么方式开局, 一个 ·能用· ·易用· ·好用· 的测试环境是必须要在第一时间阶段准备, 才能应对产品开发阶段的各项挑战.

结合我手中的几个项目, 想谈谈自己的一点关于系统测试的看法.

• XXX 4G 路由器

  此产品是利用有线宽带做接入网络,使用4G信号进行无线传输的无线设备. 设备立项阶段的设计目标为:

  • 最大支持32用户.
  • 上下行最高速率支持150Mbps.
  • 支持IpSec传输.
  • 支持Cwmp集中管理以及本地管理.
  • 支持自开站和自优化功能.

  此项目是在之前已有的平台移植进行二次开发,成立之初就发现之前单元/系统测试的极大问题. 主要暴漏在:

  • 版本迭代过程中没有良好的回归测试覆盖. 历史版本中大量出现解决一个问题又引入新问题的commit.
  • 系统测试没有自动化实践. 完全是靠人力进行弥补, 导致产品开发周期变长, 解决问题回溯历史时间很长.
  • 有关系统测试的概念不清, 只关注功能实现而忽略了系统的性能.

  这里只对最后一项进行一些实践说明,怎么才能提高产品的系统性能.

  之前产品有系统负载的测量, 主要关注在某个系统模拟负载情况下的CPU/MEMORY的性能. 但是没有对系统的整体性能进行测量.

  为什么？

  • 系统是一个软实时的设备,每个TTI(1ms)进行用户的调度,如果没有及时调度用户,会发生速率变低, 对时延敏感的响应降低. 所以需要在系统测试中加入不同模拟负载下用户的调度响应时间.
  • CPU 的利用率仅仅描述了CPU一段时间的繁忙程度, 不能够反映系统的响应. 所以需要对实时的进程进行测量, 比如当前设备运行 的 MAC, PHY 实体都是对实时性要求最高的功能实体, 需要对两者之间消息处理的时间进行监控.
  • 从用户角度出发, 需要监控从尝试接入到接入成功的时间响应, 此时间可以从另外一个维度进行系统的性能测量.

问题发现

PHY STOP

使用iPerf进行速率测试业务过程中,32UE情况下偶然会出现PHY STOP.

原因

MAC-PHY之间有3 TTI为时间窗口作为缓冲, 如果在 3ms 之内能够同步成功, 消息既可以满足要求. 如果某个时刻未能满足这个需求, 短时间内会造成速率下降, 长时间就会出现不同步现象 PHY 就会自动 STOP.

分析

使用 ftrace 分析sche info发现, MAC进程会被 IO 切换, 查看分析文件发现, MAC某处使用syslog 打印信息, syslog 默认使用本地514端口做UDP报文, 一旦超过 系统 max_tranmit_message 的容量限制, 便会成为阻塞操作, 等待 syslogd 处理消息完毕. 但是syslogd 优先级为 20的正常优先级, 即为还没有处理完socket 的内容就立刻被抢占, 导致MAC吞吐率下降.

后改为自定义的日志处理系统, 可以改善这个情况.

测试跟进

CII增加MAC-PHY消息处理响应,每周版本做跟踪处理.

IpSec 影响

IpSec 开启后系统性能下降严重.

现象

IpSec 启用后系统性能对比未使用是无论是吞吐量还是响应时间都有很大的degradation.

原因

根据ftrace 打点分析, 在ipsec 同步加密数据阶段, 消耗了太多的cpu cycle. 使得系统负载升高.

解决

使用硬件提供的协处理器进行硬件加解密功能, 降低CPU使用率. 使用 zero-copy 框架进行进一步优化.

测试跟进

对报文在各功能实体模块之间进行打点记录,每周的系统测试记录详细数据.