观远数据性能测试指导手册

性能测试指导(封面页） V1.0 版权所有©杭州观远数据有限公司2021。保留一切权利。 非经本公司书面许可，任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部，并不得以任何形式传播。 商标声明 和其他观远数据商标均为杭州观远数据有限公司的商标。本文档提及的其他所有商标或注册商标，由各自的所有人拥有。 注意 您购买的产品、服务或特性等应受观远数据商业合同和条款的约束，本文档中描述的全部或部分产品、服务或特性可能不在您的购买或使用范围之内。除非合同另有约定，观远数据对本文档内容不做任何明示或暗示的声明或保证。 由于产品版本升级或其他原因，本文档内容会不定期进行更新。除非另有约定，本文档仅作为使用指导，本文档中的所有陈述、信息和建议不构成任何明示或暗示的担保。 目录 1.概览1 2.并发性能测试2 2.1Java环境安装2 2.2JMeter部署2 2.3卡片查询脚本编写2 2.4压测线程数7 2.5测试报告8 2.6命令行模式压测9 2.7性能测试排查10 3.运算性能测试12 3.1数据准备12 3.2添加运算测试案例12 3.3测试步骤12 3.4注意事项13 4.项目案例14 4.1某大型零售集团项目性能测试背景14 4.2某大型生产集团项目性能测试背景14 5.附件清单16 1.概览 观远数据是一站式智能分析平台，面向企业提供数据分析可视化与智能决策服务，其打通数据采集-数据接入-数据管理-数据开发-数据分析-AI建模-AI模型运行-数据应用全流程，全方位提升企业数据分析的准确性与时效性，并提供可落地的经营预测和智能决策洞察，助力企业实时掌握经营状况，激发个体价值，促进组织创新，让决策更智能。 观远数据拥有强大的性能，能够快速处理海量数据。根据实际情况而言，平台性能会受到平台本身、搭配硬件、软硬件运行环境，以及具体的业务数据等因素影响。因此，为了方便部分使用环境较复杂的企业客户在本地环境进行性能测试，观远数据提供了完整的测试方案作为参考。 本方案主要覆盖两个方面的性能测试，下文将展开具体阐述。 并发性能——多用户情况下报表浏览响应时间以及用户访问高峰期的承受能力。 运算性能——大数据量下的查询计算能力。 2.并发性能测试 并发性能最能够直观体现多用户场景下的页面浏览体验以及系统在访问高峰期的事务处理能力。但是并发性能的检测离不开具体化的使用场景，不同业务的使用场景下，并发性能测试结果的数值会有极大的差异，所以需要根据自身业务选择合适场景进行测试。下文就对JMeter的安装及使用案例进行详细阐述。 2.1Java环境安装 （1）先确定电脑是否有Java环境，在电脑终端敲入：Java-Version，正确情况如下： （2）如果没有安装Java请先安装，已安装可跳过该步骤。 2.2JMeter部署 （1）下载JMeter并解压。（压缩包见附件1《apache-jmeter-5.3》） （2）双击apache-jmeter-5.3/bin/jmeter文件(mac电脑)，Windows打开apache-jmeter-5.3/bin/jmeter.bat文件可以打开工具。 （3）导入JMX脚本进行修改。（JMX脚本见附件2《1000w门店看板1-单线程 -无监听器》） 2.3卡片查询脚本编写 （1）替换登录信息 a.在谷歌浏览器中点击F12，打开前端调试工具，点击顶部Network,登录账号密码。 b.把图1中的URL替换到图3中的IP。 c.把图2中的请求体替换到图3中的BodyData。 图1 图2 图3 （2）替换卡片信息 a.替换Cookie，把Domain改为当前环境的IP。（参考上一步的IP） 图1 b.谷歌浏览器打开F12调试器，打开仪表板页面。图1中的URL替换到图3中的IP和Path。图2中的RequestPayload替换到图3中的BodyData。 c.如果需要测试多个卡片，可以把“销售额”拷贝粘贴再进行相应修改，如图4所示。 图2 图3 图4 （3）模拟不同权限用户访问 每个用户的权限不同，因此能看到的数据也不同，这时可以在卡片请求中设置变量，变量的数据存储在CSV中。 a.JMeter中新增CSV数据文件设置。(线程组-->右击-->添加-->配置元件 -->CSVDateSetConfig) b.添加内容。 c.修改卡片请求。 在卡片请求体中找到如下筛选器内容，通过$[变量名]进行替换。 d.CSV中存储文件格式。（只需要存储一列即可） （4）卡片启用与禁用 暂时不使用的Job,可以通过Disable来进行禁用；需要测试的Job,可以通过Enable来进行启用。 2.4压测线程数 一般压测线程数：50、100、150、200循序加线程进行多轮测试，取最优数据Duration：360s。 2.5测试报告 Samples：各个请求的数量。 Average：平均响应时间，单位（毫秒）默认是单个Request的平均响应时间。当使用了TransactionController时，也可以以Transaction为单位显示平均响应时间。Median：50%的用户响应时间小于这个值。 90%Line：90%的用户响应时间小于这个值。 95%Line：95%的用户响应时间小于这个值。 99%Line：99%的用户响应时间小于这个值。 Min：用户响应时间最小值。Max：用户向实践最大值。 Error%：请求的错误率=错误请求的数量/请求的总数。 Throughput：吞吐率，每秒完成处理的用户请求数。一般认为它为TPS。注意单位的变化。如上图中，当TPS很低时，JMeter中默认会统计成每分钟的值，这时我们需要换算成以秒为单位）吞吐量=请求数/总时间。 KB/Sec：每秒从服务器端接收到的数据量。 2.6命令行模式压测 （1）使用场景 a.当本地机器与服务器之间存在的网络延迟较大。 b.本地机器资源有限，压测不到接口的瓶颈。 （2）操作步骤 a.将2.2的JMeter脚本上传到Linux服务器上，并解压。 b.本地编辑完成压测JMX脚本，把脚本上传到Linux机器上的JMeter路径apache-jmeter-5.3/bin下。 c.进入apache-jmeter-5.3/bin路径下新建一个ResultReport文件夹。执行指令：./jmeter-n-ttest.jmx-lresult.jtl-e-oresultReport 参数解释： -n无UI模式运行JMeter -t需要执行的JMeter的JMX脚本文件test.jmx脚本文件 -l指定结果文件路径result.jtl测试结果文件 -e测试完成后生成测试报告 -0指定测试报告路径ResultReport测试报告 d.把测试报告ResultReport文件夹拷贝到本地，通过浏览器打开。 备注：每一次测试完成后需要把result.jtl和ResultReport文件夹下的文件清除。 2.7性能测试排查 （1）资源监控 压测过程中通过观察CPU的占比情况进行资源监控。当CPU使用率高于60%，测试出性能瓶颈。具体数据可以通过管理员设置-运维管理-资源监控进行查看。如下图。 如果存在多节点，或者双Jobserver，可以跟进分配CPU/总CPU进行计算最大占比，观察是否达到瓶颈。 （2）问题排查 如果发现压测中CPU占比较低，TPS也较低： a.查看压测脚本中线程数是否较小(可以调成100左右)。 b.查看JMeter压测机器与被压机器之间的网络是否存在较大延迟。 c.查看JMeter压测机器是否存在资源问题(一般Mac机器或者Windows机器资源较少，对大并发接口难以触达瓶颈)。 如果发现压测中CPU占比较高，TPS非常低，不满足用户需求: a.先查看卡片所使用的数据集是否较大，超过千万级别的数据集建议使用Clickhouse或者通过ETL进行拆分。 b.压测卡片中是否含有同环比、小计总计，如果存在的话，通常计算时间相对较长。 c.卡片数据集使用Clickhouse数据，需要查看筛选器是否选择了分区(例如数据集使用年作为分区，筛选器中也需要使用年)。 3.运算性能测试 观远数据平台通过直连与Guan-Index两种连接方式获取数据源数据，其中直连方式是将计算工作全部交给源数据库进行，平台本身不负担计算任务，仅在Guan-Index模式下参与计算任务，因此以下测试案例皆基于Guan-Index模式展开。 3.1数据准备 由于业务数据的自身的特征会对性能产生影响，观远数据建议使用实际业务数据或者特征相近的模拟数据来作为测试数据源。 在观远数据平台新建数据集，使用Guan-Index模式，将测试数据源中的数据抽取到观远数据平台，抽取完毕后即可基于此数据集建立测试案例。 3.2添加运算测试案例 使用基于测试数据源的数据集，新建多张表格卡片，测试基础计算性能。 （1）测试Count性能：新建计算字段Count(1)，然后拖入数值中，保存退出。 （2）测试CountDistinct性能：新建计算字段Count_distinct([测试字段])，然后拖入数值中，保存退出。 （3）测试Group聚合性能：拖入需要测试的维度和数值，保存退出。 （4）测试Group+Order性能：拖入测试维度和数值后，再将数值字段拖入到排序，保存退出。 以上四张卡片就是测试4种基础计算性能的测试案例，也可以自定义其他卡片，测试不同计算方法的性能。 3.3测试步骤 （1）记录所有测试卡片的卡片详情URL。 （2）关闭缓存和任务去重配置。观远数据BI系统默认将缓存和任务去重功能打开，以便在真实的用户使用中提升用户体验。针对性能测试，如果想在峰值时期测试产品的极限性能，进行运算性能测试时需联系观远数据相关人员进行缓存关闭，然后进行性能测试，测试完成后需要恢复配置。 （3）调整不同的压测线程数持续进行压测，每一轮测试完成后记录测试报告。 3.4注意事项 观远数据的Guan-Index模式的缓存机制在日常使用中会大幅度提升页面/卡片的访问速度，所以测试中看到的运行时长不代表实际使用中用户的等待时间。 4.项目案例 4.1某大型零售集团项目性能测试背景 数据连接方式：直连数据库：HANA BI部署服务器：阿里云初始带宽：5M 测试标准：10秒前端页面刷新出数据（非测试文档的每秒吞吐量）页面设置：单个页面4个筛选器控制20+卡片数 测试过程中出现的问题点及解决方案： （1）在缓存开关打开（有缓存）时，每一次测试间需间隔10分钟，等待上次测试产生的缓存清除后再进行测试。如此做的结果具有参考意义。 （2）用户在移动端第一次登录时会下载观远数据产品配置安装包，大约1.8m/设备，短时内多用户第一次登录会出现流量高峰。 （3）明确数据连接方式，直连情况下干扰性能因素较多，如客户数据库、网络传输情况等。后面定位单次获取数据在传输中的花费时间为4s左右，影响性能。 （4）观远数据移动端的指标卡组刷新机制，是待组内所有指标卡获取数据完毕后统一刷新，指标卡有计算字段时耗时较长，测试中出现手机超时的现象。 结合多个性能影响因素，最终解决/优化方案为： （1）涉及计算的指标卡所用数据集均从直连转为抽取，大幅提升指标卡类卡片的刷新速度。 （2）升级阿里云服务器的带宽。 （3）产品发布前用脚本刷新缓存。 4.2某大型生产集团项目性能测试背景 数据库连接方式：抽取 用户总数：约350人，请求时需要根据用户权限随机筛选数据高频访问时间：主要集中在早晨9点~10点这个区间内 页面设置：3个页面，以及其中的18个卡片，共21个请求筛选联动钻取：主要测试筛选过滤。 行列权限：有 测试过程需要注意的地方： （1）此模拟为不同用户权限请求数据的场景，