图片放在下面了,不知道为毛知乎上传的不是高清,看着真难受。
- 基准测试和性能分析
- 为什么要进行基准测试
- 测试当前应用的运行状况
- 验证系统的扩展性
- 为未来的业务增长进行规划
- 测试应用适应可变环境的能力
- 检测在不同硬件、不同软件、不同操作系统配置下的性能表现
- RAID5或RAID10 ,哪个更适合当前的系统
- 如果系统从ATA磁盘存储升级到SAN存储,是否有助于改善偶发写操作的性能?
- 使用2.4版的Linux内核是否比2.6班更好?
- 升级MySQL是否有助于性能提升?
- 针对当前应用数据使用不同存储引擎,可能会有什么效果?
- 为应用创建一个单元测试套件
- 基准测试策略
- 集成式基准测试
- 单组件式基准测试
- 选择将应用作为整体进行测试
- 需要测试的整个应用中,包括web服务器、应用代码和数据库
- MySQL并非总是应用的瓶颈,集成式基准测试往往可以揭示这点
- 只有对整个应用做测试,才能发现各个部分高速缓存的性能表现
- 集成式基准测试可以更好揭示实际应用的真实表现,而单独测试其中某一部分很难发现这点
- 测试指标
- 每时间单位的事务处理量(吞吐量)
- 响应时间或时延
- 扩展性
- 并发性
- 子主题
- 基准测试方法
- 常见错误
- 使用真实数据的一个子集,而不是全集。
- 使用错误的分布式数据
- 使用非真实的分布参数
- 在多用户应用中使用单用户想定进行测试
- 在单服务器上测试一个分布式应用
- 与真实用户行为不匹配
- 循环运行同一个查询
- 忽略错误检查
- 忽略了系统的暖机过程
- 使用默认的服务器设置
- 设计和规划基准测试
- 提出问题和明确目标
- 标准基准测试
- 示例
- 不要用TCP方法测试一个电子商务系统,他不适合OLTP系统
- 设计专用的测试
- 首先要获取一份生产数据集的快照,并确认这些数据能够恢复,可以用于后续测试
- 然后,针对这些数据运行相关查询
- 最好选择一个有代表性的时间段,记录生产系统的所有查询
- 可以在不同应用级别记录相关的查询
- 设计一些方法来归档测试参数和测试结果,并且记录每次运行都要归档
- 建立一个基准测试目录,并为每次运行建立相关的子目录。
- 获得准确测试结果
- 回答基本问题
- 是否选择了正确的基准测试
- 是否为问题搜集了相关数据
- 是否使用了错误标准来进行基准测试
- 是否对一个I/O密集型的应用,使用了CPU密集型的测试方法来评估性能。
- 注意
- 确认测试结果是否可重复
- 每次测试前,应用全新的数据快照重置系统状态
- 密切注意额外的负载(外负载),对系统保持监控性能分析,详细日志记录、周期性的作业,和其他一些因素都会影响测试结果
- 尽量少改变相关配置参数
- 对参数进行迭代式的修改
- 运行基准测试和分析测试结果
- 常见错误
- 基准测试工具
- 集成式测试工具
- ab
- apache HTTP服务器基准测试工具,可以测试HTTP服务器每秒钟最多可以处理多少web请求
- 一次只能测试一个URL连接
- http_load
- JMeter
- java应用
- 可以测试web应用
- 可以用来测试FTP服务器
- 通过JDBC接口测试执行数据库查询
- ab
- 单组件式测试工具
- mysqlslap
- database test suite
- mysql benchmark suite(sql-bench)
- Super Smack
- 专用于MySQL和PostgreSQL的基准测试工具,支持压力测试和负载生成
- 基准测试样例
- http_load
- mysql 的benchmark函数
- 测试某种具体数据库操作的执行效率,可以为函数指定一个测试循环次数和被测试的表达式
- sysbench
- 进行CPU基准测试
- 进行OLTP基准测试
- 信息
- 事务数总计
- 每秒事务处理量
- 每请求的统计信息
- 线程公平性统计信息
- 内存
- 线程
- mutex
- seqwr
- http_load
- 数据库测试工具集中的dbt2 TPC_C
- 步骤
- 准备数据
- 加载数据到MySQL数据库
- 运行基准测试
- 步骤
- MySQL基准测试集
- 集成式测试工具
- 性能分析
- 对应用进行性能分析
- 性能瓶颈可能产生的因素
- 外部资源,如web服务或搜索引擎
- 一些操作需要处理大量的应用数据,如解析(Parsing)大型XML文件
- 一些开销大的操作使用了频繁的循环处理,例如滥用正则表达式(Regular Expressions)
- 糟糕的优化算法,例如使用简单的在列表中查找项目的搜索算法
- 分析对象以及如何分析
- 建议新项目之初,就在应用加入性能分析代码
- java
- JDBC
- PHP
- mysqli database access libraries
- 性能分析代码应该收集的信息
- 总体执行时间(挂钟时间)
- 每一次查询,以及其执行时间
- MySQL服务器打开的每一个连接
- 对外部资源的每次调用,例如web服务,内存高速缓存,调用的外部脚本等
- 潜在的高开销函数调用,例如XML解析函数
- 用户时间和系统CPU时间
- MySQL 分析
- 可以得到的信息
- MySQL访问的最多的数据
- MySQL执行的最多的查询的种类
- MySQL停留时间最长的状态
- MySQL用来执行查询的使用的最频繁的子系统
- MySQL查询过程中访问的数据种类
- MySQL执行了多少种不同类型的活动,比如索引扫描。
- 记录查询
- 普通日志
- 慢速日志
- 更精细的控制日志
- 慢速查询日志存在的缺陷
- 粒度只能到秒(long_query_time的最小值为1秒)
- 不能把服务器执行的所有查询记录到慢速日志中(特别是从服务器线程的查询不会被记录)
- 慢速查询日志补丁
- 日志分析工具
- 长查询
- 影响很大的查询
- 新查询
- 分析日志的常用工具
- mysqldumpslow
- mysql_slow_log_filter
- mysql_slow_log_parser
- mysqlsla(MySQL命令分析工具)
- 分析MySQL服务器
- show status
- Bytes_received and bytes_sent(和服务器之间来往的流量)
- Handler_*(存储引擎操作)
- Select_*(不同类型的联接执行计划)
- Sort_*(几种排序信息)
- Created_*(在查询执行期间创建的临时表和文件)
- Com_*(服务器正在执行的命令)
- flush status and show session status
- flush status
- 把会话状态变量设置为0
- show profile
- 收集分析是被关闭的但是可以在会话的层面打开用于执行查询的资源的信息
- show processlist
- show innodb status
- show mutex status
- 不可添加分析代码的解决办法
- 定制网页服务器的日志,让它们记录挂钟时间和每个请求使用的CPU时间
- 使用数据包嗅探工具在查询经过网络的时候捕获和对查询进行计时(包括网络延迟)
- 使用代理,比如MySQL代理来捕获和对查询进行计时
- 服务器配置
- 分析操作系统
- 解决MySQL连接和进程故障
- netstat -ntp | grep :37636
- netstat -ntp | grep 16072/apache2
- 高级分析手段和故障解决办法
- 为什么进程处于不可中断的睡眠状态?
- strace-p
- gdb-p
- 常用的工具
- vmstat
- iostat
- mpstat
- strace
- 有用的工具
- OProfile
- Gprof
- Intel VTune
- Sun Performance Analyzer
- DTrace
- MySQL连接和进程故障
- 性能瓶颈可能产生的因素
- 对应用进行性能分析
- 为什么要进行基准测试