日常任务代码提交和接口测试还是不行啊，这周依然没恢复，大家都 能完成吗

提交 代码完不成后，接口测试也完不成了，最近几天都 这样

今天接口测试任务完成不了了，试了好几个区豆失败

哎，每天获得的码豆都在减少

【功能模块】API网关功能【操作步骤&问题现象】1、API网管进行接口测试，多次访问接口，存在接口返回为空的场景，但是在live data中测试不存在；PS：确认接口返回是有数据的2、【截图信息】【日志信息】（可选，上传日志内容或者附件）

请问有没有适用于Euler-aarch64系统的GaussDB性能测试工具？官方的验收测试和对应的工具使用时，在aarch64系统中会出现【cannot execute binary file: Exec format error】的报错。请大家推荐一下吧。

1. 安装部署（1）安装依赖软件包    dnf install –y git gcc make bison flex python net-tools（2）下载源码    git clone https://github.com/google/packetdrill.git（3）编译安装cd packetdrill/gtests/net/packetdrill./configuremake 2. 执行测试用例执行所有测试用例：cd packetdrill/gtests/net./packetdrill/run_all.py -S -v -L -l tcp/ 注意事项：1.  需要至少两张网卡2.  可以在arm/x86上执行3.  只支持python24.  对于4.19的内核在收报文时会有报错，原因是在kernel 5.3以后在TSO packets中强制添加了FLAG PSH，当前工具适配的是最新的内核

操作是正确的，却无法完成接口测试应用任务，

2 月 17 日，由信通院主办的国内首款金融数据库性能测试工具开源发布会在线上召开。会上，定位于国家高端专业智库、产业创新发展平台的信通院宣布开源了该测试工具，并详细阐述了开源此工具的背景、初心、历程以及愿景。信通院云大所副所长魏凯表示，将该款测试工具开源出来，也是希望借助平台的力量推动我国数据库产业健康、可持续地发展。国产数据库百花齐放，选型和测评成为困扰2022 年 1 月 17 日，据国际数据公司（IDC）发布的《2021 年上半年中国关系型数据库软件市场跟踪报告》显示，2021 上半年中国关系型数据库软件市场规模为 11.9 亿美元，整体市场同比增长 37.2%，IDC 预测，2021 全年中国关系型数据库软件市场规模为 27.5 亿美元， 到 2025 年将达到 76.7 亿美元，未来 5 年市场年复合增长率（CAGR）为 30.4%。毫无疑问，资本的目光紧盯上了数据库这块大蛋糕。据相关数据显示，仅在 2021 第四季度，全球数据库初创企业就募集了超过 22 亿美元的资金，国内的数据库产品更是可谓百花齐放。在全面数字化转型的过程中，数据库也迎来了换道转型的关键时期，其中最明显的变化就是云原生和分布式数据库时代真正来临了。一方面数据库产品多点开花昭示着这个行业是欣欣向荣的，这对行业来说是个利好，但另一方面，对于企业而言，要在纷繁复杂的数据库产品中选出适合自己企业的产品也愈发困难。在看到了这种现象出现后，作为信息社会创新发展的思想库和使能者，信通院也在关注数据库的 Benchmark 的实践应用及演变。技术在变、应用场景在变、产业的主体也在变，所以这也给信通院提供了一个契机和窗口，为数据库产业提出具有时代特色的 Benchmark 软件工具。在所有应用场景中，最典型的场景是金融行业，它对数据库的可拓展性、安全性、兼容性等要求是极为苛刻的。那么，应该怎样测评一款数据库是否符合当前的应用场景？此前，数据库性能测试长期依托 TPC（ Transaction Processing Performance Council，事务处理性能委员会）推出的 TPC-C 评测标准。但由于其存在工具不统一、场景不对口等问题，难以满足当前我国数据库产业新发展阶段需求。此外，TPC-C 的商品批发销售模型不能完全模拟金融机构实际业务中的事务，TPC 也不提供官方测试工具，第三方工具五花八门，测试结果难以横向比较。基于以上种种，2018 年，中国信通院联合北京银行、建设银行以及多个领域头部企业，共同设计研发了金融数据库性能测试工具（DetaBench-T)，并依托工具开展了统一标准测试，有效指导了金融行业数据库选型工作。2022 年开年之际，为使工具更快、更好地为相关方服务，信通院特将 Detabench-T 进行开源。项目开源地址：https://gitee.com/caict-bigdata/databench-t四年磨一剑，力求打造中国 TPC自 2018 年至今，信通院联合各大银行及多个领域头部企业深耕打磨的 Detabench-T，为什么选择金融行业来首次试水？据中国信通院云计算与大数据研究所业务主管刘思源介绍，2020 年，信通院从公开的数据中统计到金融业占全国的 GDP 是 8.2%，是除了制造业之外最大的一个行业。除此之外还有一个重要的原因就是金融、监管机构从 2017 年开始规划了很多政策文件，这些文件为金融信息系统向分布式架构转型的方向提出了很多的高层次指导意见。于是，从 2018 年年底开始，信通院联合了北京银行、建设银行一起来开发，并邀请了来自腾讯、华为、中兴等企业的多位专家来共同参与该款工具的总体设计和实现。DetaBench-T 工具总体架构分为三大模块，工具的总体架构图如下：刘思源表示，在我国数字化转型大背景下，很多行业都处于蓬勃发展的阶段，对于数据库这类基础软件有着极端的要求。数据库应用侧不断涌现的一些需求也在快速变化，存量市场需要替换，增量市场也要创新。但目前来说，存量市场和增量市场有两大矛盾：首先，就存量市场而言，据 2021 年信通院统计数据显示，国内已经有 80 多家数据库企业，一百多款数据库产品，今年的数据将会更多，产品的同质化竞争较为严重。但供给侧的发展相对来说并不是特别清晰，应用侧也很难在众多数据库产品中做出选择。其次，就增量市场而言，随着数字化转型的不断推进，数据和数据业务上云已经成为一种主流趋势。目前来讲，未来数据库的一些创新方向和实现路径以及应用模式还缺乏成熟的、可借鉴的经验。在这两大矛盾作用下，信通院在数据库领域的定位就很明确了，一是优化存量市场的竞争环境，对于存量市场中一些相对来说不那么适应新需求的数据库进行平稳的替代；二是找到新的数据库的发展方向，引领整个产业标准化达成共识。此次发布的 Detabench-T 工具，也是希望能从根本上推动我国 ICT 领域健康、快速发展，使工具能更快、更好地为相关方服务。文章来源：https://t.cj.sina.com.cn/articles/view/5901272611/15fbe462301901uipd声明：文章只为分享、学习，如有涉及侵权， 请及时联系删除，谢谢！

为什么要做压测的问题定位？性能测试 PTS（Performance Testing Service）是具备强大的分布式压测能力的 SaaS 压测平台，可模拟海量用户的真实业务场景，全方位验证业务站点的性能、容量和稳定性。在不断的对被压服务端水位进行摸高的过程中，我们可以从压测视图或者压测报告中看到较为全面的压测指标，例如 QPS、RT、TPS 等，但是单纯从这些指标上，是不能很快的定位到服务端具体问题所在的，例如，我们从全场景错误信息中心可以看到错误码对应的接口的响应体，但是具体在下游的哪一环节出错，以及错误的堆栈是什么，这里单纯从报告中是看不到的，而接口下游具体是哪里出错，错误堆栈是什么，正是用户所关心的问题。借助问题诊断，我们可以明确被压接口的上下游的调用情况，同时，从链路视图上，我们可以看到整条链路所经过的消息组件(Kafka、RocketMQ 等)、缓存(Redis、MongoDB 等)、数据库(MySQL、Oracle 等)、RPC 调用(Feign、Dubbo、HttpClient 等)，例如，某个接口出现状态码异常或者其他的错误，那么，我们可以从调用链上看到到底是 Rpc 调用出现问题，还是数据库读写出现问题，并且能够从调用链上看到对应的报错堆栈，在这些信息的基础上，问题应该去哪里定位也就比较明确了。问题诊断基本介绍和核心优势基本介绍谈到问题诊断，用户主要关心接入问题诊断是否需要对应用侧代码做一系列的改造，是否需要进行繁杂的配置等等。PTS 提供的问题诊断是基于 JavaAgent 的，无需用户侧做业务代码改造，对于基于 Tomcat 的部署方式，用户只需在启动脚本中添加一些必要的参数即可接入问题诊断；对于 Kubernetes 用户，用户只需在 Yaml 配置文件中添加一些必要的注解即可接入问题诊断。对于链路的采集规则，PTS 会提供默认的配置，用户也可根据自己的需要自行更改。PTS 集成的问题诊断在压测过程中，针对每条请求，会在施压引擎端生成 TraceId，通过 TraceId 将该条请求所涉及到的上下游链路关联起来，用户可以看到从该条请求作为入口到本条请求结束所涉及到的完整调用链，同时，问题诊断会针对该调用链生成相应的应用拓扑视图，可以让用户清晰地看到应用之间的调用关系。针对异常的接口，我们可以在调用链中看出对应的错误原因，同时，用户可以根据具体的报错堆栈对服务端的问题进行排查和优化。压测过程中用户可以实时的查看指定请求的调用链，同时，压测结束之后，也可以从压测报告中对问题进行回溯。核心优势1、零代码侵入： 针对 Java 类型的服务，用户侧无需进行业务侧代码改造即可完成问题诊断的探针接入。2、集成度高： 压测、监控、问题诊断，集成在同一控制台，用户理解和操作成本相对较低。3、监控指标全： 在压测过程中，除了较为基础的监控指标外，同时针对每个服务，提供接口、机器、应用级别的监控。 4、门槛低： 仅需要简单配置参数即可完成问题诊断探针接入，同时该探针还具备多协议 Mock、全链路压测等功能。快速玩转问题诊断接入问题诊断的基本流程图如下所示：接入探针，并查看是否接入成功首先，我们将被压场景所涉及到的应用梳理出来，将涉及到的所有应用按照【问题诊断】->【探针接入 [1] 】文档中的步骤进行问题诊断探针接入。我们可以在 PTS 控制台的应用配置或者应用监控、接口监控、机器监控中任选一个来查看应用探针是否接入成功。我们本次演示的压测场景涉及到五个应用，分别是 petstore-web、petstore-user、petstore-order、petstore-catalog、petstore-cart，这以应用监控举例来查看应用是否成功接入。依次点击 PTS 控制台的【问题诊断】->【应用监控 [2] 】->选择我们配置的 Region 以及 Namespace，如果看到压测场景涉及到的所有应用均在该页面，则代表应用接入成功。在压测场景中打开问题诊断开关然后，我们在 PTS 控制台的【压测中心】->【创建场景 [3] 】中创建压测场景，这里可以选择 PTS 场景或者 JMeter 场景等，这里以 PTS 场景为例，因为本次演示主要是验证问题诊断的能力，所以需要在场景配置中的【高级设置】中打开问题诊断开关。具体的监控采集规则，PTS 会为用户推送默认采集开关打开的配置，同时，将采样率设置为千分之一，用户也可根据自己的需要进行自定义。开始压测，查看应用监控完成了以上步骤，我们的压测场景即具备了问题诊断的能力。当我们点击开始压测之后，可以到应用监控、接口监控、机器监控中选择我们关心的服务查看对应的监控情况，这里以应用监控 [2] 为例，其他类型的监控操作步骤类似，我们选择 petstore-user 这个服务来查看应用监控，如下图所示：压测结束后，查看全场景错误信息压测结束后，我们需要从压测报告中针对被压服务端的问题进行排查，打开对应场景的压测报告，具体步骤：PTS 控制台->【压测中心】->【报告列表 [4] 】，选择对应的压测报告，可以从概览页中看到全场景的信息，具体如下图所示：选择探针采样，查看具体调用链情况点击【查看采样日志】，采样类型选择”探针采样“即可过滤出问题诊断探针所采集到的调用链，具体如下图所示：查看调用链具体错误堆栈信息，定位服务端问题所在筛选出来探针端采集的调用链之后，即可对存在问题的接口进行调用链分析，例如，商品列表的接口返回的状态码为 500，点击查看详情看下具体原因，如下图所示：从调用栈中可以看到具体的报错原因，从而对服务端代码进行优化和修复。同时，可以通过应用拓扑视图和数据库视图查看服务之间的调用情况以及数据库使用情况，这里以应用拓扑视图举例，如下图所示：压测报告常见错误码总结问题诊断错误码总结问题诊断调用链路中的常见错误码进行总结，具体如下：java.lang.NullPointerException：服务端空指针，具体可根据调用链中的错误堆栈对服务端的代码进行排查。com.microsoft.sqlserver.jdbc.SQLServerException：服务端 SQL 报错，可根据调用链采集的堆栈信息对服务端 SQL 语法等进行检查。压测报告错误码总结这里针对压测报告中常见的错误进行列举，我们可以从全场景错误信息中看到相关的错误信息，具体如下：class java.net.SocketTimeoutException:null 表示请求在等待响应或者读取中途（idle）超时。请检查服务端健康状况或者 PTS 的压测 API 超时时间的设置是否合理，另外还有可能是服务端处理能力出现瓶颈。class java.net.ConnectException:null 表示请求在与远端（被压测端）建立 TCP 连接时就出现失败或者被远端拒绝。请检查服务端健康状况，或者是网络连接层是否有瓶颈。class java.util.concurrent.TimeoutException:null 表示请求在与远端（被压测端）建立 TCP 连接时就出现失败或者被远端拒绝。请检查服务端健康状况，或者是网络连接层是否有瓶颈。class org.apache.http.ConnectionClosedException:Connection closed 表示连接异常关闭，服务端主动关闭了连接。class java.io.IOException:Connection reset by peer 表示连接被重置。若使用了 SLB，请查看 SLB 的配置是否有问题。class org.apache.http.ConnectionClosedException:Connection closed unexpectedly 表示数据尚未接收完毕，连接就已关闭。可能服务端未及时响应或者提前终止调试或压测。class java.lang.RuntimeException:java.net.UnknownHostException 表示域名信息无法解析。请检查域名是否已经正常注册并可以解析、未注册的域名是否已进行域名绑定。class org.apache.hc.core5.http.ProtocolException:Header 'key: value' is illegal for HTTP/2 messages 表示在服务端优先使用 HTTP2 协议的情况下，场景配置了 HTTP2 协议不支持的 Header，请移除相应Header后重试。HTTP2 不支持的常见 Header 有：Connection、Keep-Alive、Proxy-Connection、Transfer-Encoding、Host、Upgrade。

利用python发送第一个请求关于HTTP请求，建议大家提前了解一下，再来看该篇文章该篇文章以简单的登录接口为例，干货来了：首先利用python发请求就会用到request库，先导入进来import requests1导入该库之后，就开始代码主体部分了#首先我们要把我们要测试接口API写进来url="http://localhost:8080/jwshoplogin/user/login.do"#紧接着把我们需要的参数定义一下userinfo={"username":"大娟",           "password":"Aa111111"}#参数定义完成后，就该让这个请求带着这个参数去乖乖的请求服务器了，下面的代码意思为将响应回来的信息以文本格式给到resres=requests.post(url,data=userinfo).text#得到响应信息后，将他打印出来print(res)这个为该接口正常响应回来的信息，作为测试我们当然要写个断言来判断他响应回来的对不对嘛，#.find这个方法是在响应回来的信息里面找登录成功四个字，找不到会返回-1负一的值msg=res.find("登录成功")if msg>0:    print("测试通过")else:    print("测试失败")一个简单的接口测试就这么完成了。将请求参数进行参数化处理这时候我们用到的是csv文件，现将csv库倒进来,还有我们必要的request库import requestimport csv下面是代码主体，具体解释我会写进代码里url='http://localhost:8080/jwshoplogin/user/login.do'#上面url就不解释了，但是userinfo我要说下，这里为空是因为我一会在文件里读取的内容放到这里面userinfo={}#下面的两个是对文件的操作，r为对文件读（read）,w为对文件写（write）file1=open("interfacePara.csv",'r')file2=open("loginResult.csv","w")#这个意思为将读出来的内容放到table里面table=csv.reader(file1)for row in table:#第一次循环#将读到的第一行第一列的值给到username    userinfo["username"]=row[0]#将读到的第一行第二列的值给到password    userinfo["password"]=row[1]#这时候userinfo拿到的值为username="大娟",password="Aa111111"    response=requests.post(url,data=userinfo).text#查看一下响应回来的信息    print(response)    print(row[2]) #在响应回来的信息里面找csv文件里的第一行第三列的值，然后做判断，写到文件loginResult.csv里面    r=response.find(row[2])    if r>0:        print("测试通过") #因为在csv文件里每个分割是用逗号分割的所以这个要加上逗号，而且是英文格式的大家不要搞错，"\n"是换行的意思        file2.write(row[0]+","+row[1]+","+row[2]+","+"测试通过"+"\n")    else:        print("测试异常")        file2.write(row[0] + "," + row[1] + "," + row[2] + "," + "测试失败" + "\n")

在所有组件都安装和对接完成后，可以运行一次全量的自动化测试任务来检查数据平台的安装和对接结果。使用BO资产的租户用户登录AppCube平台。选择“管理 > 应用管理 > 应用导航”。搜索“AutomationTest”，单击自动化测试应用后面的预览。在“测试任务管理”中单击“全量验收测试”后面的执行按钮。执行完成后，在执行记录里找到“全量验收测试”。单击查看执行记录查看按钮查看详细的用例执行结果。如果有失败的用例，需要根据用例的日志（日志的查看方法请参考自动化用例错误日志检查）解决环境的问题，重新执行4进行检查。在AppCube生产环境上自动化测试工具只能在系统商用前运行，在系统正式商用后请不要再运行自动化测试任务。

【功能模块】智慧园区自动化测试【操作步骤&问题现象】1、自动化测试中 自带的测试用例，需要进行配置吗 ？有的可以测试通过，有的不能通过2、【截图信息】【日志信息】（可选，上传日志内容或者附件）============================= test session starts ============================== platform linux -- Python 3.7.5, pytest-6.0.1, py-1.9.0, pluggy-0.13.1 rootdir: /opt/service/pytest-service/apps/Hi-zq2021, configfile: pytest.ini plugins: ordering-0.6 collected 1 item Hi-zq2021/A02_模拟第三方消息上报/test_03_电表状态上报.py 2021-12-17 10:42:07,371 [INFO] =================== [post] [CommonService] =================== 2021-12-17 10:42:07,371 [INFO] request_url: https://192.168.9.163:1443/httpconnector/message 2021-12-17 10:42:07,371 [INFO] request_headers: {'Content-Type': 'application/json', 'X-HW-ID': 'Hi-zq2021__io.basepoint.connectionmax.iot', 'MsgTopic': 'T_IO_DEVICE_DATACHANGED__Hi-zq2021', 'MsgTag': 'tag-pytest', 'MsgBusinessId': 'id-pytest', 'X-HW-APPKEY': 'vCR8hxTblRQgU3nMAK5efw=='} 2021-12-17 10:42:07,371 [DEBUG] request_body: { "platformId": "basepoint.connectionmax.iot", "notifyType": "deviceDataChanged", "requestId": "287358764596", "eventTime": "20211217104207", "deviceId": "ElectricityMeter001", "gatewayId": "gateway12345678", "messageCode": "1", "data": { "onlineStatus": "1" } } 2021-12-17 10:42:07,372 [INFO] =================== [get] [获取ROMA登录公钥] =================== 2021-12-17 10:42:07,372 [INFO] request_url: https://studioroma.e.huawei.com/roma/sso/key 2021-12-17 10:42:07,373 [INFO] request_headers: {'Content-Type': 'application/json'} 2021-12-17 10:42:07,489 [INFO] response_cost: 0.116216 s 2021-12-17 10:42:07,489 [INFO] response_status_code: 200 2021-12-17 10:42:07,580 [INFO] =================== [post] [登录ROMA] =================== 2021-12-17 10:42:07,581 [INFO] request_url: https://studioroma.e.huawei.com/roma/asset-m2mservice/1.0/tokens 2021-12-17 10:42:07,581 [INFO] request_headers: {'Content-Type': 'application/json'} 2021-12-17 10:42:07,921 [INFO] response_cost: 0.340611 s 2021-12-17 10:42:07,922 [INFO] response_status_code: 200 F =================================== FAILURES =================================== ___________________________________ test_run ___________________________________ Hi-zq2021/A02_模拟第三方消息上报/test_03_电表状态上报.py:35: in test_run request.send() /opt/pytest/SmartCampusBVTest/public/core/http_request_impl.py:54: in send ??? /opt/pytest/SmartCampusBVTest/public/core/http_request_impl.py:137: in __send_request ??? /opt/pytest/SmartCampusBVTest/public/core/abc_proxy.py:24: in run ??? /opt/pytest/SmartCampusBVTest/public/service/RomaService.py:335: in get_app_key ??? /opt/pytest/SmartCampusBVTest/public/service/RomaService.py:475: in login ??? E KeyError: 'csrf_token' =========================== short test summary info ============================ FAILED Hi-zq2021/A02_模拟第三方消息上报/test_03_电表状态上报.py::test_run - K... ============================== 1 failed in 0.89s ==================

问题背景描述使用sysbench对mysql5.7.21进行256并发压测时，x86下TPS为10685，Kunpeng920 下压测结果为4197，性能较原有X86环境下有较大差距。 问题分析过程Top命令查看cpu资源使用情况       执行脚本进行压测时发现，top命令下mysql进程cpu使用率6000%左右，其中系统调用占用较高，为进一步明确mysql进程在执行哪些过程进行perf 热点函数和火焰图分析。perf命令查看热点函数通过在压测过程中执行perf top命令，查看到相关函数调用较高：进一步明确分析函数调用栈关系，使用perf record命令抓取一段时间perf 数据，进行解析后生成相应火焰图：分析发现mysql中调用的热点函数MVCC::view_open和PolycyMutex_在底层调用的是spin_lock相关函数，进而导致系统调用高，大量线程都在进行自旋空转，消耗cpu资源。问题解决措施及结果修改Mysql源码中CacheLine(可选优化项)通过github上mysql相关issue发现，在mysql中存在对cacheLine的硬编码现象，mysql中cachline大小是适配X86平台的为64字节，Kunpeng 920下cacheLine为128字节。可参考以下issue链接cid:link_2对mysql源码进行修改，此措施可获得相应的性能提升。Cacheline机制理解：CPU标识Cache中的数据是否为有效数据不是以内存位宽为单位，而是以Cacheline为单位。这个机制可能会导致伪共享（false sharing）现象，从而使得CPU的Cache命中率变低。出现伪共享的常见原因是高频访问的数据未按照Cacheline大小对齐，而在高并发压测mysql时，其中加锁的全局变量或数据一般是在高频的访问，这就可能导致性能的下降。（对于高频访问的锁变量，实际是对锁变量进行高频的读写操作，容易发生伪共享问题）修改mysql数据库配置参数Mysql中主要影响spin_lock相关性能参数的主要有：innodb_thread_concurrency、innodb_spin_wait_delay、innodb_sync_spin_loops。其中nnodb_thread_concurrency推荐设置为cpu的核心数，通过上调innodb_spin_wait_delay和innodb_sync_spin_loops参数，同时使用perf top命令观测MVCC::view_open和PolycyMutex_热点函数使用率，当使用率下降到合理范围内时，即达到预期效果。由于原子操作在x86和kunpeng 920平台上的实现存在差异，加上kunpeng920的核心数较多，导致在mysql高并发压测时出现了spin_lock相关系统调用较高，通过相应的mysql参数优化即可实现性能提升，结合Mysql下相关自旋锁的代码实现，可更好的理解这两个参数的作用，参考链接如下：cid:link_1优化后测试结论       通过对mysql的相关优化，最终在256并发下，kunpeng 920上TPS达到了11700,优于原X86压测结果(TPS 10685)。