zoukankan      html  css  js  c++  java
  • 性能测试系列(2):性能报告

    测试简介

    测试背景

    简述本次性能测试的项目背景,如:当前礼品卡系统,高频访问的查询相关接口都是从数据库中查询,这会导致系统的吞吐量比较低,无法应对后续用户量爆发式增长时候的高峰期的用户高并发请求

    测试目标

    简述本次性能测试的目标,如:为了解决用户量达到千万级别的高峰期请求

    测试内容

    测试环境

    业务架构图

    生产架构图:
    测试架构图:

    测试环境配置

    测试环境数据

    测试结果

    模块

    性能情况概述

    TPS:

    RT:

    聚合报告:

    服务器性能统计

    1. 硬件性能统计:

    2. JVM中间件性能统计:

    3. MYSQL数据库性能统计:

    瓶颈分析

    本功能点的瓶颈在于mysql数据库中查询 t_order表时以del_flag为其中一个查询条件,但是del_flag只有0和1两个值,导致查询效率慢。
    本功能点的测试结果是在t_order表50万基础测试数据,符合查询范围的条数为1万条基础上得到的结果;我试验了下最极端的测试数据,即t_order表50万数据全部都符合查询条件,那么这条查询语句也就相当于全表扫描了,测试结果为TPS=2笔/秒,平均每条查询SQL的执行时间在1.6-1.8秒左右,效率是相当慢的。线上环境目前还没有足够多的订单数据,但是随着以后业务量的不断扩大,订单表数据量肯定不止这个数量级,我们可以考虑将表拆分,分字段建多张表,或者将这个查询业务放在非MYSQL数据库的其他服务上来完成。

    测试结果汇总

    模块 功能点 虚拟用户数 单节点TPS 响应时间 系统瓶颈点

    测试总结

    测试结论

    根据之前的所有的测试结果给出综合性测试结论,一般包括是否满足业务需求,系统目前的性能指标及变化趋势和最优配置等。如:
    经过了不同目的的测试执行工作,对系统的性能有了相对全面的了解,下面是测试总结:
    (1) 系统在单机(参照测试环境软硬件配置信息)上已经能够满足当前及预估的未来3年的业务增长需求,不存在TPS、响应时间、CPU、内存、磁盘、网络等瓶颈
    (2) 对系统的负载性能做了评估,暂无性能风险。系统性能拐点在并发40个线程时,提供的总吞吐量为4100
    (3) 进行了配置测试,在满足当前性能及未来业务增长的情况下,建议JVM Heap设置为4g,Tomcat最大连接数为12000,最大并发数为1200;linux下用户最大线程数设置为unlimited
    (4) 进行了稳定性测试,执行了1小时以上。业务量为需求的10倍以上。从结果看,不管是响应时间还是TPS都比较稳定,事务成功率100%,没有明显影响性能的现象
    综上,接口能够满足性能要求,当前硬件设备情况下性能有保障

    系统缺陷

    给出系统存在的缺陷

    系统风险

    给出系统存在的性能风险点。如:随着用户规模的增加预计系统的首要风险在Redis,需要重点关注

    优化建议方案

    给出对应的优化建议方案,如,目前可以满足业务需求量场景,继续加大用户量首先进入瓶颈的为cpu,建议服务器升级CPU配置

    作者:Cstzar

    -------------------------------------------

    个性签名:君子藏器于身,待时而动

    如果觉得这篇文章对你有小小的帮助的话,记得在右下角点个“推荐”哦,博主在此感谢!

  • 相关阅读:
    关内存地址的分配
    关于URL
    linux的8小时差问题解决
    关于Scanner类
    域名后缀
    匿名对象用法
    final修饰符,多态,抽象类,接口
    二维数组的传参
    关于随机数
    面向对象编程的三大基本特征
  • 原文地址:https://www.cnblogs.com/cstzar07/p/14015811.html
Copyright © 2011-2022 走看看