• nmon问题定位和LoadRunner结果分析


    一. 场景设计回顾

    1. 在我们实际工作中,一般是先做单场景(单接口)的性能测试,当没有问题后,或者优化之后,再做混合场景,这是基于以下两点考虑

    (1) 为了更好的排查问题,更好的优化问题

    (2) 当多个接口混合的时候,也会出现一些相互调用的其他问题

    2. 稳定性场景:建议也是用混合场景,一般跑8个小时,这个时候,可能出现之前没有出现的问题,比如说内存溢出

    二. 单个用户并发和多个用户并发为什么效果一样?

    1. 只要数据量比较多,比如用户表里有15万数据,进行同一个手机号登录的时候,也会出现性能问题

    2. 就算进行参数化操作,和一个用户的效果是一样的,参数化只是为了模拟真实的情况,但是多个参数化的用户名还是会出现同样的用户进行登录

    三. 定位mysql慢查询的步骤

    1. 最好在做性能测试之前,对于mysql数据库,需要在/etc/my.cnf配置里配置好慢查询信息

    #打开慢查询:1表示打开
    slow_query_log=1
    #慢查询的日志保存路径--自定义的
    slow_query_log_file=/opt/mysql/mysqllog/logfile/slow-query.log
    #慢查询的时间,只要达到这个时间,就会在日志里打印
    long_query_time=1

    注意:修改配置文件后,需要重启mysql服务:service mysqld restart

    2. 跑性能测试场景,看我们场景里面的响应时间,如果一直上升并且超过了1s,TPS一直很低

    3. 运行nmon,输入c,看CPU的资源使用情况,一般只要关注use%(用户态)的CPU占用,如果超过90%,一般都是慢查询语句导致的

    4. 在nmon里面输入t,看是哪个进程导致的,如果mysql进程导致,一般是慢查询的问题

    可以看到是mysql进程导致的,CPU使用率过高

    5. 在我们的慢查询日志里面查询日志信息

    输入:tail -f /opt/mysql/mysqllog/logfile/slow-query.log 

    6. 找到并复制日志里的sql语句:

    tail -f /opt/mysql/mysqllog/logfile/slow-query.log 

    Query_time:查询这条语句需要多长时间

    7. 复制sql到mysql的客户端里,加上EXPLAIN查看

    8. type=ALL,是没有索引,或者索引失效,进行全表扫描

    rows:表示查找这一个条件需要查询多少行

    注意:

    (1) oracle数据库也有慢查询,不过是用awr报告,方法和这个有些差别

    (2) nmon是监控系统资源使用情况的,要监控哪台机器就放到哪台机器上

    (3) 做性能测试的时候,一定要有自己的独立性能环境,自己管理,自己部署

    四. LoadRunner结果

    1. 认识Analysis

    比如事务通过率为4个9-->99.99%

    Std.Deviation:标准方差,方差是描述一组数据偏离其平均值的情况

    方差越大:这组数据越离散,波动性越大

    方差值越小:波动性越小,也说明我们这个接口性能越稳定,处理能力比较平稳。但不能说明这个接口的性能就比较好

    2. 90 Percent:表示90%的事务响应时间都维持在某个值附近

    3. pass:与脚本做if判断的作用关联起来

        if(atoi(lr_eval_string("{code}")) == 0) {
               lr_end_transaction("登录", LR_PASS);
           } else {
               lr_end_transaction("登录", LR_FAIL);
           }
        

    4. Http Responses:从HTTP层面来看,发送HTTP请求成功的信息,200,并不代表事务是成功的。与Pass的数量并不一定相等

    5. 每秒点击率:点击率与客户端的性能有关,跑脚本的时候需要关注本机的性能情况,如果出现90%以上,你本机需要更换更好的配置来跑,不要用工作机器跑性能。需要申请服务器,比如16C,16G内存的机器跑性能

    6. 一般做性能测试的时候,不需要太多关注吞吐量,因为吞吐量小,那么TPS也就小。我们只要关注TPS就可以了

    7. 响应时间:当标准方差比较大的时候,会出现概要报告里的响应时间和指标里面的响应时间不相等,这个时候,应该选择90%的响应时间来作为我们的平均响应时间

    8. TPS:在做性能测试的时候,接口的响应时间不能超过500ms,中型企业,起码是500ms以内,TPS达到500-800,小型企业之一300左右,之前的公司都是1k+

    这个和传统的web页面的2 5 8(2s,5s,8s)不一样

    9. 其他操作

    (1) 截取某个时间段的图表

    (2) 合并操作

    面试题:TPS低,响应时间高,是什么原因导致的?

    步骤:

    (1) 查看服务器的资源使用情况,如果是use% CPU很高,就要定位到是哪个进程导致的

    (2) 查看服务器的资源使用情况,如果系统资源的使用情况很低,可能出现的原因有:

    a. 查看网络情况,最直接的方法,ping 服务器ip地址 -t,看看有没有丢包的情况,如果有丢包,说明带宽不够,也有可能是跨网段做性能测试了

    b. 如果没有丢包,并且是千兆网卡,再查看客户端的请求有没有真正发出去,看本机的性能情况

    c. 连接数:看Tomcat应用的连接数,Tomcat连接数据库的连接数,数据库本身的连接数

  • 相关阅读:
    repeater 设置分页
    table表格合并
    repeater分页
    http错误500.19 错误代码 0x80070021
    asp文件上传和下载
    asp:Repeater控件使用
    vs2013标签
    "Uncaught SyntaxError: Unexpected token <"错误完美解决
    监控系统说明文档
    限制input输入类型(多种方法实现)
  • 原文地址:https://www.cnblogs.com/my_captain/p/12643649.html
Copyright © 2020-2023  润新知