软件性能测试(连载7)

简介: 软件性能测试(连载7)
6CPU状态转换

CPU状态转换如图3-18所示。

 

image.png

3-18  CPU状态转换图

7)软中断与硬中断

假设现在一家公司就有一名客服人员,这个客服人员就有一台座机,这种情况下用户碰到问题只能打电话给这个客服人员,如果有多个用户同时打入只能凭运气,先打通电话的人得到回答,其他人只能依次等待。显然这种处理机制是非常低效的,小公司可能还可以,大一点的公司就不行了。于是现在共有4-5位客服人员,建立总分机架构,1位负责总机(也可以交给语音提示来操作),负责把问题分给4个分机,让4个分机人员来处理具体的问题,这样一来效率就明显提高了。如果客户来电,总机负责人接电话分给分机人员(或通过语音提示用户拨打分机号)叫做硬中断,而分机负责人处理具体问题叫做软中断。LinuxCPU正是采用硬中断与软中断结合的方式来处理问题的。比如现在网卡告诉CPU,有一批数据要从网络中过来,希望系统做好接收准备,CPU手头的工作被打断(中断),将网络上的数据存储在寄存器中,然后呼起一个进程来处理后续操作,就回头处理刚才中断之前的工作了。被呼起的进程可以在后台“慢慢地”地把寄存器中的数据按照规定格式写入数据库中。这里CPU处理的过程就为硬中断过程,而进程把数据写入数据库中过程为软中断过程。具体如图3-19所示。

image.png

3-19  软中断与硬中断


硬中断可以用命令cat /proc/interrupts来查看,而软中断可以用cat /proc/softirqs来查看。由于硬中断比软中断过程短得多,所以作为性能监控往往需要监控软中断。

#cat /proc/softirqs
     CPU0       CPU1
HI:      0          0
TIMER:    811613    1972736
NET_TX: 49         7
NET_RX: 1136736         1506885
BLOCK: 0         0
IRQ_POLL:  0          0
TASKLET: 304787             3691
SCHED:    689718    1897539
HRTIMER:      0          0
RCU:   1330771         1354737


其中。

TIMER

定时产生的软中断。

NET_RX

网络接收产生的软中断。

NET_TX

网络发送产生的软中断。

SCHED

内核调度产生的软中断。

RCU

RCU产生的软中断。


扩展阅读:RCU

[32]RCU(Read-Copy Update),顾名思义就是读/拷贝/修改。对于被RCU保护的共享数据结构,不需要获得任何锁就可以访问它,但写者在访问它时首先拷贝一个副本,然后对副本进行修改,最后使用一个回调(callback)机制在适当的时机把指向原来数据的指针重新指向新的被修改的数据。这个时机就是所有引用该数据的CPU都退出对共享数据的操作


另外也经常使用ps aux | grep softirq命令来查看产生中断进程。

#ps aux | grep softirq
root        7  0.0  0.0     0     0 ?        S   Oct10   0:01 [ksoftirqd/0]
root       16  0.0  0.0     0     0 ?        S   Oct10   0:01 [ksoftirqd/1]


注意:[]为内核进程,可见软中断进程属于内核进程。

top命令中也可以看到软中断进程。

#top
top - 10:50:58 up 1 days, 22:10,  1 user, load average: 0.00, 0.00, 0.00
Tasks: 122 total,  1 running,  71 sleeping,   0 stopped,  0 zombie
%Cpu0 :  0.0 us,  0.0 sy, 0.0 ni, 96.7 id,  0.0 wa,  0.0 hi, 3.3 si,  0.0 st
%Cpu1 :  0.0 us,  0.0 sy, 0.0 ni, 95.6 id,  0.0 wa,  0.0 hi, 4.4 si,  0.0 st
...

 

 PIDUSER      PR  NI VIRT   RES    SHR S  %CPU %MEM    TIME+      COMMAND

 7    root     20  0  0      0       0 S     0.3 0.0      0:01.64   ksoftirqd/0

  16   root    20  0  0      0       0 S     0.3  0.0     0:01.97   ksoftirqd/1

2663root      20  0 923480 28292  13996S  0.3 0.3      4:58.66   docker-containe

3699root      20  0 0        0     0 I      0.3 0.0      0:00.13   kworker/u4:0

3708root      20  0 44572   4176   3512 R 0.3  0.1      0:00.07  top

   1root      20  0 225384   9136  6724 S 0.0  0.1      0:23.25  systemd

   2root      20  0 0         0     0    S   0.0 0.0      0:00.03  kthreadd


除了可以使用cat /proc/softirqs查看当前软中断状态,在实际工作中也常常使用watch -d cat /proc/softirqs来动态显示实时软中断状态。


案例3-12:小包问题
#watch -d cat /proc/softirqs
          CPU0        CPU1
HI:       0           0
TIMER:   1083906   2368646
NET_TX:   53      9
NET_RX:   1550643  1916776
BLOCK:    0           0
IRQ_POLL:0          0
TASKLET: 333637    3930
SCHED:   963675     2293171
HRTIMER: 0           0
RCU:      1542111   1590625


上面结果中可以看出,网络发送产生了大量软中断。然后通过sar -n DEV 1命令来进一步分析。

#sar -n DEV 1
15:03:46 IFACE        rxpck/s txpck/s   rxkB/s    txkB/s   rxcmp/s txcmp/s rxmcst/s   %ifutil
15:03:47eth0         35645.00 6304.00  857.43   358.11    0.00     0.00   0.00         0.01
15:03:47docker0      6302.00 12604.00 270.79    664.66   0.00     0.00   0.00          0.00
15:03:47 lo           0.00     0.00      0.00     0.00      0.00      0.00   0.00        0.00
15:03:47 veth9f6bbcd6302.00   12604.00 356.95   664.66   0.00     0.00    0.00        0.05


在这里。

15:03:46

表示报告的时间。

IFACE

表示网卡名。

rxpck/stxpck/s

分别表示每秒接收、发送的网络帧数,也就是PPS

rxkB/stxkB/s


分别表示每秒接收、发送的千字节数,也就是BPS

在上面结果中,857txpck/s)×1024/35645rxpck/s= 24字节,说明平均每个网络帧只有24字节,这显然是很小的网络帧,也就是通常所说的小包问题。确定是小包是问题后,就可以使用类似tcpdump工具进行进一步排查了。


8CPU使用率

CPU使用率=1-CPU空闲时间/CPU总时间。

平均CPU使用率=1- (CPU空闲时间New- CPU空闲时间Old)/ (CPU总时间New- CPU总时间Old)

top命令显示了系统总体的CPU和内存使用情况,以及各个进程的资源使用情况。而ps命令则只显示了每个进程的资源使用情况。


9CPU节拍率

CPU节拍率指每秒钟CPU切换的次数,单位为HZ一般为:100HZ250HZ1000HZ,如果CPU节拍率为250HZ,表示:每秒钟触发250次切换,即每次切换持续1/250sCPU节拍率可以通过grep 'CONFIG_HZ='/boot/config-$(uname -r)命令得之。

#grep 'CONFIG_HZ=' /boot/config-$(uname -r)
CONFIG_HZ=250

如图3-20所示,当前Memory中有“0”“1”“2”“3”“45个请求等待CPU处理。在当前时间段内CPU处理第“2” 号请求,过了1/250s(假设CPU节拍率为250),处理第“3”号请求,然后依次循环处理“4”“0”“1”…号请求。

image.png

3-20  CPU节拍率

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
目录
相关文章
|
10天前
|
机器学习/深度学习 人工智能 自然语言处理
深入探索软件自动化测试的有效性与挑战
【5月更文挑战第27天】 在软件开发生命周期中,测试环节是确保产品质量的关键步骤。随着技术的进步,自动化测试成为提高测试效率和准确性的重要手段。本文深入分析自动化测试的优势、面临的挑战以及未来发展的方向。通过实际案例分析,探讨如何优化测试流程,提升自动化测试的覆盖范围和可靠性。同时,针对自动化测试中的常见问题提出解决方案,并预测自动化测试的未来发展趋势。
|
2天前
|
测试技术 程序员 开发者
软件测试项目式学习一(认识软件生命周期与开发模型及软件质量)
软件测试项目式学习一(认识软件生命周期与开发模型及软件质量)
|
7天前
|
安全 物联网 测试技术
构建未来:Android与IoT设备的无缝交互深入探索软件自动化测试的未来趋势
【5月更文挑战第30天】在物联网(IoT)技术快速发展的当下,Android系统因其开放性和广泛的用户基础成为了连接智能设备的首选平台。本文将探讨如何通过现代Android开发技术实现智能手机与IoT设备的高效、稳定连接,并分析其中的挑战和解决方案。我们将深入挖掘Android系统的底层通信机制,提出创新的交互模式,并通过实例演示如何在Android应用中集成IoT控制功能,旨在为开发者提供一套可行的指导方案,促进IoT生态系统的进一步发展。
|
8天前
|
设计模式 并行计算 算法
代码之韵:高效编程的艺术深入理解软件自动化测试框架的设计与实现
【5月更文挑战第29天】在数字世界的构建中,编程不仅仅是一门科学,更是一种艺术。本文将探讨如何通过理解编程的本质、掌握设计模式、运用算法智慧以及持续的性能优化过程,来提升编程效率和代码质量。我们将从宏观的架构设计到微观的代码细节,剖析那些让代码更加优雅、高效且易于维护的技巧与实践。
|
8天前
|
敏捷开发 监控 Java
深入理解与应用软件自动化测试框架
【5月更文挑战第29天】在软件开发的快速迭代过程中,自动化测试已经成为保证产品质量和提升开发效率的重要手段。本文旨在探讨自动化测试框架的选择、搭建及优化实践,通过对现有自动化测试工具的分析以及真实案例的应用,为开发者和测试工程师提供一套高效、可靠的自动化测试策略。文中不仅介绍了几种主流的自动化测试框架,还详细讨论了如何根据项目需求定制测试脚本,并提出了持续集成中自动化测试的最佳实践。
|
9天前
|
人工智能 算法 测试技术
探索软件自动化测试的未来:AI驱动的测试策略构建高效可靠的微服务架构:后端开发的新范式
【5月更文挑战第28天】 在软件开发的世界中,测试是确保产品质量的关键步骤。随着技术的进步和项目复杂性的增加,传统的手动测试方法逐渐显得力不从心。本文旨在探讨自动化测试的最新趋势——人工智能(AI)驱动的测试策略。我们将分析AI如何通过智能化的测试用例生成、测试执行优化以及结果分析来提高测试效率和精确性。文章还将讨论实施AI测试策略的挑战与机遇,为软件测试工程师提供未来技术转型的视角。 【5月更文挑战第28天】 在当今软件开发的快速迭代和复杂多变的环境中,传统的单体应用架构已经难以满足业务敏捷性和可扩展性的需求。微服务架构作为一种新的解决方案,以其服务的细粒度、独立部署和弹性伸缩等特性,正逐
|
10天前
|
设计模式 敏捷开发 监控
深入探究软件自动化测试的策略与实践深入理解PHP中的命名空间
【5月更文挑战第27天】 在软件开发周期中,确保代码质量是至关重要的一环。随着敏捷开发和持续集成的普及,自动化测试成为提升效率和保障软件质量的重要手段。本文将详细探讨自动化测试策略的制定、工具选择以及在实际项目中的执行过程。我们将从自动化测试的基本原则出发,分析不同类型和级别的自动化测试案例,并结合具体实例,讨论如何优化测试流程,减少冗余,提高测试覆盖率和准确性。通过阅读本文,读者将获得一套实用的自动化测试实施框架,以支持其在快速迭代的开发环境中维护高水平的软件品质。 【5月更文挑战第27天】在本文中,我们将探讨PHP中的命名空间(namespace)的概念、用途和实现方式。通过详细解释命名
|
12天前
|
敏捷开发 测试技术 持续交付
深入探索软件自动化测试的有效性与挑战
【5月更文挑战第25天】本文聚焦于软件自动化测试在现代软件开发周期中的有效性与其面临的挑战。通过对自动化测试的概念、优势及实施过程中可能遇到的问题进行详尽分析,旨在为读者提供一种系统的视角来理解自动化测试的重要性及其在实际应用中的复杂性。文章不仅阐述了自动化测试如何提高测试效率和准确性,还讨论了在不同开发环境中实现自动化的策略和最佳实践,以及如何解决常见的技术和非技术障碍。
|
12天前
|
敏捷开发 存储 数据管理
深入探索软件自动化测试框架的设计与实践
【5月更文挑战第25天】随着软件开发周期不断缩短,传统的手动测试方法已难以满足快速迭代的需求。本文将深入剖析自动化测试框架的设计原则和实践应用,探讨如何通过有效的策略和技术手段提升测试效率和质量。文章首先介绍自动化测试的重要性及其在现代软件开发中的作用,然后详细阐述自动化测试框架的核心组件、结构设计以及关键技术点,最后通过案例分析展示自动化测试框架在实际项目中的应用效果。
|
14天前
|
Java 测试技术 持续交付
深入理解与应用软件自动化测试框架
【5月更文挑战第23天】 随着软件开发周期的不断缩短和发布频率的加快,传统的手动测试方法已难以满足快速迭代的需求。因此,本文将深入探讨自动化测试在现代软件开发中的关键作用,特别是自动化测试框架的设计与实现。文章首先回顾了自动化测试的基本概念和核心优势,接着详细分析了几种流行的自动化测试框架(如Selenium、Appium和JUnit)的特点及应用场景。然后,重点讨论了如何根据项目需求选择适合的测试框架,以及如何构建一个可靠且易于维护的自动化测试环境。最后,通过实际案例分析,展示了自动化测试框架在提高测试效率和确保软件质量方面的实践成效。