基准测试方法
在了解基本概念之后现在可以来具体讨论下如何设计和执行基准测试但在讨论如何设计好的基准测试之前先来看一下如何避免一些常见的错误这些错误可能导致测试结果无用或者不精确
使用真实数据的子集而不是全集例y 如应用需要处理几百GB 的数据但测试只有GB 数据或者只使用当前数据进行测试却希望模拟未来业务大幅度增长后的情况
使用错误的数据分布例如使用均匀分布的数据测试而系统的真实数据有很多热点区域（随机生成的测试数据通常无法模拟真实的数据分布）
使用不真实的分布参数例如假定所有用户的个人信息（profile）都会被平均地读取注
在多用户场景中只做单用户的测试
在单服务器上测试分布式应用
与真实用户行为不匹配例如Web 页面中的思考时间真实用户在请求到一个页面后会阅读一段时间而不是不停顿地一个接一个点击相关链接
反复执行同一个查询真实的查询是不尽相同的这可能会导致缓存命中率降低而反复执行同一个查询在某种程度上会全部或者部分缓存结果
没有检查错误如果测试的结果无法得到合理的解释比如一个本应该很慢的查询突然变快了就应该检查是否有错误产生否则可能只是测试了MySQL 检测语法错误的速度了基准测试完成后一定要检查一下错误日志这应当是基本的要求
忽略了系统预热（warm up）的过程例如系统重启后马上进行测试有时候需要了解系统重启后需要多长时间才能达到正常的性能容量要特别留意预热的时长反过来说如果要想分析正常的性能需要注意若基准测试在重启以后马上启动则缓存是冷的还没有数据这时即使测试的压力相同得到的结果也和缓存已经装满数据时是不同的
使用默认的服务器配置第 章将详细地讨论服务器的优化配置
测试时间太短基准测试需要持续一定的时间后面会继续讨论这个话题只有避免了上述错误才能走上改变测试质量的漫漫长路
如果其他条件相同就应努力使测试过程尽可能地接近真实应用的情况当然有时候和真实情况稍有些出入问题也不大例如实际应用服务器和数据库服务器分别部署在不同的机器如果采用和实际部署完全相同的配置当然更真实但也会引入更多的变化因素比如加入了网络的负载和速度等而在单一节点上运行测试相对要容易在某些情况下结果也可以接受那么就可以在单一节点上进行测试当然这样的选择需要根据实际情况来分析是否合适
返回目录高性能MySQL
编辑推荐
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
Oracle索引技术
