带着ChatGPT玩转软件开发-连载26

我有一个朋友，他们开发了一套系统，只要提供各种测试用例，设计需求文档，用他们产品即可帮助您们公司生成自动化测试的运行，有兴趣的可以加我与他们联系。

测试用例没有也无所谓，关键把业务流程与产品结构、网络架构写清楚即可，即开发平时所需要的文档，与playwrite实现的不是一种东西。可以理解一边输入文档（有用无用该产品自动会去辨认），然后另一边就可运行测试了。

我们订于1月12日演示这个产品，希望大家参加

https://meeting.tencent.com/dw/pbel4WXrzEfC

试用地址

http://47.100.231.216:8083/atnest/

guxiang

AiTest.12300

顾老师新作“带着ChatGPT玩转软件开发”将于今年底明年初出版

5.3 ChatGPT执行分析性能测试数据

由于条件所限，本书被测机是一台虚拟机，这是不符合性能测试环境的，标准的开发环境调优阶段的性能测试环境应该是压测机和被测机在同一网段内，不同的主机上，有条件可以将数据库独立出来。读者关键掌握的是如何利用ChatGPT进行性能调优的思路。

5.3.1找到登录并发测试的临界点

在本次测试中，采用二分法来确定登录并发测试的临界点。当错误率控制在5%以下，且发生错误>=5%的最小并发值与发生错误>5%的最大并发值的差值在50以下的时候，认为找到了并发临界点，这个时候测试可以结束。这里设置第一次并发用户数为1000，开始测试。测试数据详见表5-1。

表5-1电子商务登录功能并发测试数据

注意：并发用户为5000的时候，错误率为6.47%；而并发用户为3000的时候，错误率为0.06%，所以下一次设置可以试图尽量向5000靠近些，不需要完全按照二分法来设置。

根据计算，3532与3563之间的差值为31（即3563-3532=31），这一数值小于50。当在线用户数为3563时，错误率为6.86%（>5%）；而当在线用户数降至3532时，错误率为2.18%（<5%）。因此，判断登录性能并发测试的临界点为3532。

5.3.2 ChatGPT监控分析拐点处性能

监控工具使用nmon_x86_64_ubuntu23，在被测端启用以下命令。

./nmon_x86_64_ubuntu23-f-s 5-c 120

重新启动压测程序，将在线用户数设置为3532。

5.3.3 ChatGPT分析压测结果

1.压测端

1）结果图

测试运行结束后，提取了汇总图，如图5-2所示。

图5-2 压测端汇总图测试数据

具体的图形结果见图5-3。

图5-3压测端图形结果测试数据

2）压测端数据

提示词

JMeter测试概要结果。

本章数据参见本书配套代码Performent_Test_Data\性能测试数据.docx。

数据5-1第一组JMeter压测数据

…

请帮助分析压测端测试性能结果。

3）ChatGPT分析

ChatGPT回答

根据您提供的JMeter测试概要结果，我们可以通过几个关键指标来分析压测的性能。

1.响应时间

•登录页面的平均响应时间是495毫秒，虽然在可接受的范围内，但对于用户体验而言，可能还可以进一步优化，特别是在高并发情况下。

•登录成功页面的平均响应时间相对较高，为1477毫秒，这可能会影响用户体验，尤其在用户访问量较大时。

•另外两个阶段（"登录成功页面-0"和"登录成功页面-1"）的响应时间分别为1100毫秒和284毫秒，其中后者要好得多。

2.最大响应时间

•登录成功页面的最大响应时间为31128毫秒（31.1秒），这表明在某些情况下，响应时间可能非常慢，可能是由于系统瓶颈或后端服务器的性能问题。需要深入调查导致响应时间延迟的具体原因。

3.异常率

•登录页面的异常率为0.107%，登录成功页面的异常率为10.683%，这表明在高流量情况下，登录成功页面的可用性问题显著，可以引起关注并进行优化。异常率高可能会导致用户无法正常登录。

4.吞吐量

•吞吐量的指标（样本数/每秒）显示出整体的吞吐量为2054.28，表明系统在承受高负载时仍能保持较高的请求处理能力，但要关注每个功能模块的吞吐量，特别是响应时间较高的登录成功页面。

5.接收和发送数据速率

•总体接收速率为2332.39KB/sec，而发送速率为0.00KB/sec，表明网络层与应用层之间的交互相对良好，但需要确认是否存在数据发送问题（例如API调用后未返回数据的情况）。

6.标准偏差

•每个页面都呈现出不同程度的标准偏差，尤其是登录成功页面的标准偏差为2372.68，说明其响应时间的波动较大，进一步确认其性能一致性问题。

7.建议

•对于登录成功页面的性能优化，可以考虑检查后端处理效率、数据库查询效率、以及是否存在资源竞争的问题。

•加强对异常请求的监控，查找具体的异常原因，分析是否有重复的请求导致异常或者请求异常产生的原因。

•考虑增加负载均衡或优化系统架构，以应对高并发情况下的性能挑战。

•可以设置更严格的性能监控和警告机制，以便在正常使用情况下及时发现性能下降或异常的现象。

总之，测试结果显示应当关注的性能瓶颈和潜在风险点，通过优化和监控可以提升整体用户的体验。

注解：下面通过生成的nmon文件对被测端进行分析。

2.被测端系统

1）SYS_SUM数据

提示词

数据5-2 第一组SYS_SUM

…

帮助分析一下性能。

2）ChatGPT分析

ChatGPT回答

根据您提供的系统性能统计数据，我们可以从几个方面来分析性能状况。

1.磁盘I/O性能

•平均磁盘tps(Transactions per second)

Ø平均磁盘tps:333。

Ø此值表示在指定的时间间隔内，每秒处理的磁盘事务数量。333的平均值表明系统的磁盘I/O负载适中。

•最大磁盘tps

Ø最大磁盘tps:8696。

Ø这个峰值相当高，表明在某个时刻系统经历了极高的磁盘活动。这可能意味着某些特殊的I/O密集型操作（例如大型数据加载或备份）正在进行。

•磁盘I/O读写比

Ø读写比:1.0。

Ø说明读操作和写操作相对均衡，这通常是健康的表现，表明系统在正常水平上进行数据读写。

2.CPU使用情况

•CPU使用百分比

Ø用户CPU%:28.7%。

Ø系统CPU%:53.9%。

Ø等待CPU%:0.2%。

Ø空闲CPU%:17.2%。

Ø总CPU%:82.7%。

Ø这里的使用情况显示系统相对繁忙，尤其是系统CPU%较高，表明内核处理的系统级操作（如I/O请求处理）较多。

•高峰CPU使用情况

Ø最大用户CPU%:35.3%。

Ø最大系统CPU%:61.4%。

Ø最大等待CPU%:5.8%。

Ø最大空闲CPU%:99.6%。

Ø在高峰期间，CPU负载达到了93.9%，这显示出在高负载时系统对CPU的要求较高。

3.结论

整体来看，您的系统在平均情况下表现出良好的读写平衡及适中的磁盘I/O。高峰的tps显示出在某些特定时刻可能存在性能瓶颈，特别是在CPU使用率达到了较高水平时。系统在处理较高的I/O请求时，CPU可能会受到压力。

4.建议

•监控高峰时段:进一步监控和分析在最大tps的情况下，是否有特定的进程或操作造成了这种情况。

•优化高CPU使用:如果系统在高张力情况下，可以考虑检查和优化正在运行的应用程序，减少不必要的I/O或CPU操作。

•扩展资源:如果经常出现高负载情况，考虑是否需要扩展硬件资源（如增加CPU、内存或更快的磁盘存储）。

这些措施可以帮助提高系统的整体性能与稳定性。

3.被测端CPU

提示词

1）CPU_ALL数据

数据5-3第一组CPU_ALL

…

2）CPU_SUMM数据

数据5-4 第一组CPU_SUMM

…

帮助分析一下性能。

3）ChatGPT分析

ChatGPT回答

根据您提供的CPU相关数据（CPU_ALL 和 CPU_SUMM），我们可以对系统的性能进行如下分析。

1.CPU_ALL数据分析

•CPU使用率概况

Ø从CPU_ALL数据中可以看到CPU使用率波动很大。从14:15:30的13.1%到14:25:27的92.3%都有较大幅度的变化。

Ø在14:15:55到14:16:30之间，CPU使用率达到峰值，系统CPU%一直在55%到60%之间波动，且有多个时段（如 14:18:00 以后）又回到了较高的90%以上，这显示出CPU在这个时间段内的工作负载非常高。

•用户和系统CPU%

Ø用户CPU%和系统CPU%在大多数时间内都较高，特别是系统CPU%经常维持在55%到60%的水平。这表示系统需要花费大量时间在内核模式下运行，这可能是I/O操作或其他系统级别的活动导致的。

Ø有些时候用户CPU%会偶尔降为0，表示该时段内没有用户进程在运行。

•等待和空闲时间

Ø等待CPU%一直维持在接近0%，这意味着在大多数时间内，系统没有太多进程处于等待状态。相对来说空闲CPU%在某些时刻也达到了70%以上，表明在负载较低的时段，CPU有不少空闲时间。

2.CPU_SUMM 数据分析

•每个CPU的使用情况

ØCPU_SUMM中显示了四个CPU的使用情况，用户和系统CPU%都在 27%到30%之间，系统CPU%在52%到55%之间。这显示出系统负载相对均匀地在四个CPU之间分配。

Ø从这四个CPU的使用情况来看，无论是用户还是系统负载都接近，说明系统的负载平衡良好。

3.结论

•高CPU使用:系统在某些时段内的高CPU使用率（尤其是系统CPU%大于55%）表明系统负载较重，可能存在性能瓶颈。

•负载平衡:四个CPU的使用率相对均匀，表明负载分配良好。

•等待状态:等待状态较低，说明可能没有严重的I/O等待问题，但是CPU使用率过高提示需要关注。

4.建议

•监控和优化:应进一步监控CPU使用率高的时间段，找出哪些进程导致了高负载，并考虑对其进行优化。

•硬件资源扩展:如果高负载状态是常态，可能需要考虑扩展硬件资源，例如增加更多的CPU核心或提高计算能力。

•性能调优:考虑对经常占用CPU的应用程序进行性能调优，减少不必要的系统资源占用。

•查看I/O操作:如果CPU占用高，而I/O占用也高，可能需要评估存储性能，并微调应用的I/O效率。

4.被测端磁盘

提示词

帮助分析磁盘数据。

1）DISKBSIZE数据

数据5-5 第一组DISKBSIZE

…

2）DISKBUSY数据

数据5-6 第一组DISKBUSY

…

3）DISKREAD数据

数据5-7 第一组DISKREAD

…

4）DISKWRITE数据

数据5-8 第一组DISKWRITE

…

5）DISKXFER数据

数据5-9 第一组DISKXFER

…

6）ChatGPT分析

ChatGPT回答

在分析给定的磁盘数据时，我们可以关注几个关键指标来评估性能，包括磁盘块大小（Disk Block Size）、磁盘忙碌度（Disk %Busy）、磁盘读取和写入速度（Disk Read/Write KB/s）以及每秒磁盘传输率（Disk transfers per second）。根据这些数据，我们可以得出以下分析：

1.磁盘块大小(DISKBSIZE)

•数据在短时间内有很大的波动，尤其是在14:17:11（最高 75.9）和 14:22:26（最高302.3）时能看到异常高的值。

•这种波动可能是因为系统执行了较大的I/O操作导致的。

2.磁盘忙碌度(DISKBUSY)

•平均值：sda3为2.5，sda为2.0。这表明两个磁盘在测试期间的占用情况都相对较低。

•最大值：sda3为63.1，sda为44.7。这也是在高负载读写操作时的结果。

•除了高峰期间外，大多数时间段磁盘的忙碌程度都较低，显示出两个磁盘在大部分时间里都处于闲置状态。

3.磁盘读取速率(DISKREAD)

•平均读取速度

Øsda3：1037.9KB/s。

Øsda：1038.2KB/s。

•最大读取速度

Øsda3：28776.4KB/s。

Øsda：28777.2KB/s。

•读取率在期间内也出现了极大的波动，这可能与高峰时的读操作量增加有关。最明显的峰值发生在14:15:55和14:16:00。

4.磁盘写入速率(DISKWRITE)

•平均写入速度

Øsda和sda3都为1039.5KB/s。

•最大写入速率

Øsda和sda3都为17578.7KB/s。

•在数据的历史上，写入速率表现出更大的波动，尤其在上下文中高峰期的写入速率显现出系统的高负载（尤其是在14:15:55时达到14186.2KB/s）。

5.每秒磁盘传输(DISKXFER)

•平均传输率

Øsda3：165.7transfers/s。

Øsda：165.8transfers/s。

•最大传输率：sda3和sda的最大传输率都达到了高峰（sda3：4348.2transfers/s），表明在特定的时间点，这两个磁盘的I/O操作非常繁忙。

6.综合分析

•性能高峰和低峰：两个磁盘均表现出高负载下的性能波动。特别是在14:15:55及之后的一段时间，可能由于系统执行了大量的读写操作。

•闲置时间较多：在高负载期间之外，磁盘的忙碌度很低，说明平时磁盘的利用率较低，未达到一个高效的使用状态。

•优化空间：可以考虑通过负载均衡、优化I/O操作或增加磁盘数量来提高整体性能，尤其是在高负载时，系统的响应能力可能受到影响。

整体来看，在高强度的I/O负载下，系统表现出较强的读写能力，但在休闲时段，磁盘利用效率不高，可以进一步调整以优化性能表现。

5.被测端内存

1）MEM数据

提示词

帮助分析内存数据。

数据5-10 第一组MEM

…

2）ChatGPT分析

ChatGPT回答

根据您提供的内存数据，这是一段关于一台名为jerry-virtual-machine的虚拟机的内存使用情况记录。我们可以对这些数据进行分析，以帮助您理解该虚拟机内存的使用状况。

1.数据列解释

具体每列的意义如下。

•时间戳:记录的时间。

•memoryMB:系统总内存（MB）。

•memtotal:总内存（具体数值，看起来为0，需要检查）。

•hightotal:高性能内存总量（通常为0）。

•lowtotal:常规内存总量（呈现为2140MB）。

•swaptotal:总交换空间（2140MB）。

•memfree:可用内存（随着时间变化）。

•highfree:可用高性能内存（通常为0）。

•lowfree:可用常规内存（随着时间变化）。

•swapfree:剩余交换空间（随着时间变化）。

•memshared:共享内存量（通常在小范围变化）。

•cached:被缓存的内存（随着时间变化）。

•active:活跃内存（使用中的内存较大，随着时间变化）。

•bigfree:大块可用内存（可能用于大块分配）。

•buffers:缓冲区内存（通常较小，随着时间变化）。

•swapcached:缓存的交换内存（通常较小）。

•inactive:不活跃内存（随时间变化）。

2.数据分析

•内存使用情况

Ø总内存:保持在1920.4MB左右，可以认为这是虚拟机的总内存。

Ø可用内存:在所有时间记录中memfree表示系统可用内存，变化范围相对较大。可用内存最低为约90MB，最高达到230MB，说明虚拟机的内存资源相对紧张。

•交换空间

Øswapfree:虚拟机的交换空间也经历过明显变化，较高时为1131MB。说明在内存紧张时，虚拟机使用了部分交换空间来缓解压力。这可能导致性能下降，尤其是在内存达较低值时（如97.3MB）。

•缓存

Øcached总是较高（286.4MB到怀851.6MB不等），表示系统使用了相当多的内存来存储缓存数据以提高系统性能。这对应持续的I/O性能提升，但在内存紧张时会回收这些缓存内存。

•活跃与不活跃内存

Øactive内存相对于其他数值来看比较高，表明许多进程正在使用内存。

Øinactive内存时常在640MB左右，表明有一定量的内存占用处于不活跃状态。

•性能考虑

Ø根据这些数据，您可能会注意到在可用内存低的情况下，虚拟机的性能可能会受到影响。如果在memfree小于100MB 时频繁出现，建议考虑增加内存或优化运行的服务和应用程序。

3.建议

•监控内存使用：继续监控内存使用状况，确保在高峰期不会因为内存不足导致系统触发交换或出现延迟。

•优化应用程序：检查和优化内存使用较高的应用程序，必要时可以调整其内存

4.设置

•考虑调整内存配置：如果虚拟机负载持续较高且经常接近内存临界值，考虑增加虚拟机配置中的内存。

这些数据有助于您了解虚拟机的实时内存使用情况，并可以为后续优化提供依据。

6.被测端网络

1）Network数据

提示词

帮助分析网络数据

数据5-11 第一组Network

…

2）NETPACKET数据

数据5-12 第一组NETPACKET

…

3）ChatGPT分析

ChatGPT回答

根据提供的网络数据，我们可以进行以下分析：

1．数据概览

•数据分为两组：网络IO（Network I/O）和网络数据包（NETPACKET）。

Ø每组数据都包含时间戳，显示了不同网络接口的读取和写入速率（单位：KB/s或packets/s）以及总计的读取和写入速率。

•网络I/O（Network I/O）分析

Ø流量变化趋势

◆网络流量在一段时间内有明显波动。

◆在14:15:30到14:16:45之间，读取和写入速率逐渐上升，达到峰值。

◆从14:16:51之后，读取和写入速率波动性减少，趋于稳定。

Ø读取和写入速率

◆ens33接口的读取和写入速率显著高于lo和docker0接口。

◆lo（本地回环）接口的流量非常小，基本可以忽略。

◆docker0（Docker桥接网络）接口在这些时间段没有数据。

Ø负值分析

◆Total-Write(-ve)列中存在负值，这表示写入速率大于读取速率，可能意味着系统中正在进行大量写入操作，而读取的速度跟不上。

•网络数据包（NETPACKET）分析

Ø数据包数量

◆网络数据包的发送和接收在某些时间段显著增加，尤其是在14:16:00到14:17:50之间。

◆此时发送/接收的数据包速率达到最高值，可能与某些网络活动或应用负载相关。

Ø流量持续性

◆数据包的读取速率在整个数据集中基本保持在高水平，显示网络活动持续活跃。

◆存在多个高峰期，可用作检测异常或故障排查的参考（例如，可能的DDos攻击或其它网络请求高峰）。

Ø各接口数据包比较

◆ens33的读取和写入速率总是显著高于lo接口，而docker0接口没有任何活动

◆从平均值看，ens33接口的读取和写入持续处于较高水平，显示该接口承担了主要的网络流量。

2.总结与建议

•监控建议

Ø由于网络流量在高峰期时剧烈变化，建议对ens33接口的流量进行持续监控，以便及时发现可能的故障或者异常。

•性能调优

Ø如果出现了性能瓶颈或延迟，可能需要考虑对后台写操作进行优化，确保数据写入不影响网络性能。

•倾向性分析

Ø定期进行此类数据的收集和分析，结合应用使用情况可以帮助改善网络架构设计，合理分配资源以及进行故障排查。

通过对比和分析这些数据，您可以获得对系统网络性能的深入理解，以及在出现问题时更快地定位根源。

顾翔凡言：AI时代，掌握已知的未知已非难事，关键在于如何发现未知的未知——而它往往就藏在探索已知之未知的过程中。