为什么很多人在新机器上线后不想做基准测试,无非是繁琐,耗时, 以及很难度量. 不是非常标准化的采购安装部署,主机总难免有些缺陷, 所以,如果有一个脚本,可以把cpu,磁盘,网络,数据库 都预先压测一遍,就可以省事多了.
我写下一些测试指引,方便大家构建 MySQL的测试模型:
1. 当我们选择硬件的时候,我们需要考虑到各项成本,对于项目风险,开发成本,维护成本比较难以衡量,而计算机性能相对来说是更好限定和比较,所以考虑建立一个MySQL的基准测试模型;
2. 单个工具产品的基准测试,主要用于对比版本和衡量软硬件调整的效果,对于整个应用系统的测试没有什么参考意义,应用系统基准测试模型会比单个MySQL测试模型更全民准确;
3. 如果是ssd盘,建议文件最大空间不超过总空间的85%,以避免ssd硬盘空间占比可能带来的性能下降;
4. 除了考虑吞吐率(TPS),还需要考虑响应时间(response time);
5. 只测试innodb,不对比myisam,因为生产环境不建议使用myisam,myisam引擎的表崩溃后数据文件会损坏;
6. 衡量MySQL性能需要考虑诸多因素,包括但不限于以下一些因素:
* 硬件:cpu速度,cpu架构,cpu个数,cpu核数,总线速度,内存访问速度,裸设备io性能,raid卡,磁盘条带,块大小,网络设备,io调度算法,
* os: 原生api文件性能,线程,锁,内存
* 客户端连接次数
* 数据库服务器处理任务的线程个数.
* 数据库设计
* 数据量
* 应用类型
* 数据访问模式 : 一般来说我们的应用热点数据较小,读原大于写.如果你的应用热点数据比较大,访问各种数据比较分散,比较均匀,那么这种测试更考验了数据库的原始性能)
* 数据库版本: 社区版 or 企业版 or 其他非官方版本
* 引擎 : 如二进制包自带的innodb 和 innodb plugin的对比.
* 数据库配置. 比如numa策略,pagesize大小, 独立表空间 or 共享表空间, 顺序访问和随机访问文件的分布, buffer pool 以及其他一些影响重大的参数.(略)
