zoukankan      html  css  js  c++  java
  • mysql基础测试

    测试原因

     
    为什么需要做性能测试
    • 模拟比当前系统更高的负载,找出性能瓶颈
    • 重现线上异常
    • 测试不同硬件软件配置
    • 规划未来的业务增长
     
    测试分类

     
    性能测试的分类
    • 设备层的测试
    • 业务层的测试
    • 数据库层的测试
     
    设备层的测试
    • 关注哪些指标
      • 服务器,磁盘性能
      • 磁盘坏块率
      • 服务器寿命
     
    业务层测试
    • 针对业务进行测试
     
    数据库层的测试
    • 什么情况下要做Mysql的测试
      • 测试不同的Mysql分之版本
      • 测试不同的mysql版本
      • 测试不同的mysql参数搭配
     
    mysql测试分类
    • CPU Bound --全内存的测试,测试的数据远小于配置的内存;这样就可以不用因为磁盘IO的性能不同,而影响测试结果。
    • IO  Bound-- 测试的数据量远大于内存,这就有大量的数据从磁盘IO读取写入;
     
    4小类:
    • 写入测试
    • 更新测试
    • 纯度测试
    • 混合模式(根据业务不同)
     
    常用的测试工具
    • 开源的mysql性能测试工具
      • sysbench
      • tpcc-mysql
      • mysqlslap
    • 针对业务编写性能测试工具
      • blogbench--根据网易博客,的具体业务来做的测试工具
     
    性能测试衡量指标:
    • 服务吞吐量
      • TPS--每秒执行事务的总量
      • QPS--每秒执行的请求总量
    • 服务响应时间
    • 服务并发性---正在工作中的并发操作,或者是同时工作中的线程数或者连接数。例如一个web站点"同时有50000个用户"访问,却可能只有10--15个并发请求到mysql数据库,此时并发数只有10--15。
    • 可扩展性---------------简单来说,给系统增加一倍的资源(比如两倍的CPU数),就可以获得两倍的吞吐量。当然,同时性能(响应时间)也必须在可以接受的范围内。大多数系统是无法做到如此理想的线性扩展的。
     
    测试方法

     
    设计基准测试的常见错误:
    • 使用真实数据的子集而不是全集。
    • 与真实用户行为不匹配。
    • 没有检查错误。-----------测试中遇到不是预期结果,就应该检查错误日志,这时基本要求。
    • 忽略了系统预热的过程----系统重启后,缓存是没有数据的,这时测试与实际情况不符,实际很可能是 缓存中已经有很多数据。
    • 测试时间太短
     
    1 测试规划:
    • 记录测试数据
    • 系统配置的步骤
    • 如何测试的步骤
    • 分析结果
    • 预热的方案
     
    应该建立将参数和结果文档化的规范,每一轮测试都必须进行详细记录
     
    2  基准测试应该运行多长时间
     
    一个简单的测试规则,就是等系统看起来稳定的时间至少等于系统预热的时间。
     
    基准测试应该运行足够长的时间。
     
    如果没有实际去完成准确完整的基准测试,那么已经花费的所有时间都是一种浪费。有时候要相信别人的测试结果,这总比做一次半拉子的测试来得到一个错误的结论要好。
     
    3  获取系统性能和状态
     
    需要记录的数据包括系统状态和性能指标:
    • cpu使用率
    • 磁盘I/O
    • 网络流量统计
    • show global status 计数器等
    使用脚本对这些数据进行收集。
     
    基于mysql的默认配置的是没有什么意义,因为默认配置是基于消耗很少内存的极小应用的。
     
    4 运行基准测试并分析结果
     
    自动化基准测试,是个不错的方案。可以是一个makefile或者一组脚本。
     
    要尽可能地使用所有测试过程都自动化,包括数据装载,系统预热,执行测试,记录结果。等。
     
    多次测量
     
    5 绘图的重要性
     
    通过图形可以立刻发现一些问题,而这些问题在原始数据中却很难被注意到。
     
    在执行基准测试的时候要尽可能收集更多的细节数据,然后将数据绘制成图形,这样可以帮助快速地发现问题。
     
    gnuplot或者R绘图;
     
    测试工具

     
    Sysbench
    • 业界较为出名的性能测试工具
    • 可以测试磁盘,CPU,数据库
    • 支持多种数据库:oracle,DB2,MYSQL
    • 需要自己下载编译安装
    • 建议版本:sysbench0.5
     
    sysbench,不仅用来测试数据库的性能,也可以测试运行数据库的服务器的性能。
     
    强烈建议熟悉sysbench测试,在mysql用户的工具包中,这应该是最有用的工具之一。
     
    • sysbench 的cpu基准测试
    • sysbench 的文件I/O基准测试
    • sysbench 的OLTP基准测试
     
    sysbench 其他的基准测试,但和数据库性能没有直接关系。
    • 内存-----测试内存的连续读写性能
    • 线程-----测试线程调度器的性能。
    • 互斥锁---测试互斥锁性能。
    • 顺序写---测试顺序写的性能。
     
     
    Tpcc-mysql
     
    • TPC-C是专门针对联机交易处理系统(OLTP系统)的规范
    • Tpcc-mysql由percona根据规范实现
    TPCC流程  更能模拟线上业务
    使用该测试工具:需要创建数据和表结构,加载数据,执行测试三个步骤。
     
    benchmark()
    mysql的benchmark():可以测试某些特定操作的执行速度。
     
    复制代码
    mysql> set @input := 'hello world';
    Query OK, 0 rows affected (0.00 sec)
     
    mysql> select benchmark(1000000,MD5(@input));
    +--------------------------------+
    | benchmark(1000000,MD5(@input)) |
    +--------------------------------+
    |                              0 |
    +--------------------------------+
    1 row in set (1.45 sec)
     
    mysql> select benchmark(1000000,SHA1(@input));
    +---------------------------------+
    | benchmark(1000000,SHA1(@input)) |
    +---------------------------------+
    |                               0 |
    +---------------------------------+
    1 row in set (1.40 sec)
    复制代码
    虽然benchmark()函数用起来很方便,但是不适合用来做真正的基准测试,因为该函数只是简单地返回服务器执行表达式的时间,不会涉及分析和开销,等因素。
    而且表达式必须像这个例子一样包含用户定义的变量(input),否则会多次执行同样的表达式会因为系统缓存命中而影响结果。
     
    具体测试实践,请看sysbench实践,tpcc-mysql实践;
     
     总结

     
    •  四小类:写入测试,更新测试,纯度测试,混合模式
    •  性能测试衡量指标:
      •  服务吞吐量
        •  TPS--每秒执行事务的总量
        •  QPS--每秒执行请求的总量
      •  服务响应时间
      •  服务并发性
    •  设计测试常见错误:
      • 使用数据子集而不是全集,
      • 与真实用户行为不匹配,
      • 没有检查错误,
      • 忽略了系统预热过程,测试时间太短;
    • 测试方法
      •  测试规划:
        • 记录测试数据,
        • 系统配置步骤,
        • 测试步骤,
        • 分析结果,
        • 预热方案;
      •  测试时间:测试应该运行足够长的时间,至少等于系统预热的时间。
      •  获取系统性能和状态:cpu,IO,网络流量,mysql状态计数器;
      •  运行测试:自动化测试包含:数据装载,系统预热,执行测试,记录结果。
      •  绘图分析:直观的发现问题;
      •  测试工具:sysbench,tpcc-mysql,benchmark()
    •  测试小结:
      •  IO Bound测试数据量要远大于内存,cpu Bound测试数据量要小于内存
      •  测试时间建议大于60分钟,减小误差;有系统预热时间;
      •  Sysbench更倾向于测试Mysql性能,Tpcc更接近于业务
  • 相关阅读:
    一个简单的knockout.js 和easyui的绑定
    knockoutjs + easyui.treegrid 可编辑的自定义绑定插件
    Knockout自定义绑定my97datepicker
    去除小数后多余的0
    Windows Azure Web Site (15) 取消Azure Web Site默认的IIS ARR
    Azure ARM (1) UI初探
    Azure Redis Cache (3) 创建和使用P级别的Redis Cache
    Windows Azure HandBook (7) 基于Azure Web App的企业官网改造
    Windows Azure Storage (23) 计算Azure VHD实际使用容量
    Windows Azure Virtual Network (11) 创建VNet-to-VNet的连接
  • 原文地址:https://www.cnblogs.com/youngerger/p/9022954.html
Copyright © 2011-2022 走看看