性能测试报告
网上的许多测试报告/包括厂商的产品报告往往具有误导性。如果说普通的用户做测试，往往是因为对于软硬件知识的欠缺，情有可原，但厂商特别是夸大其词的公司，则应该被鄙视，比如Tokyo Cabinet这些产品 ，市场的考验是无情的，只靠营销或者吹捧，往往没有生命力。
那么我们应该如何看待一份正常的测试报告呢 ？
我想，
至少需要说明测试的场景，服务器的软硬件配置，物理部署和数据流。
对于自己的测试结果，要尽可能的加以详细的说明，可能不得不接受一个现实，解析测试结果已经超过了测试人员的知识范围里，特别是被一些额外的外来因素影响。
如果测试出现了一些性能/容量上的差异，那么应该简明扼要的说明是哪些因素导致的？
如果同时调整了太多参数，然后得出一个结论，往往不具备说服力，应该尽可能地少调整参数，然后加以对比，除非你对参数调整的效果非常有经验。
如果对比许多类不同的产品，往往准确性不够，可信度不高，网上的各种一下子列举出5，6，7，8种NOSQL产品，然后加以对比的测试报告，建议持有一定的怀疑。
对一些数据库/[……]
Read more
mysql基准测试模型(4) 基准测试的不足.
1. 不容易测试其他的系统特性:稳定性,安全性,扩展性,可用性,灾难恢复性等等 ;
2. 没有计算成本(磁盘,内存,…..) ,但即使计算了成本,也可能被厂商欺骗,厂商会使用最优的配置,以尽可能低的成本支撑更大的吞吐;
3. 没有衡量能源消耗;
4. 没有考虑到复杂的网络环境;
5. 用户考虑得是 这个产品能够满足何种服务品质协议(service-level agreement) (比如说99.99%的时间是可用的) ,而基准测试考虑的更多是能够达到的平均分数.
一般报告列出的可能是80-90%的的系统资源使用率,不考虑系统资源严重瓶颈,而现实中往往并非如此,在系统资源严重瓶颈下的的性能,安全性,稳定性可能急剧下降.
## mysql基准测试模型介绍.
## 组合以下不同条件:测试类型,线程数,表个数,表记录数(大小) 进行测试
## ================开始测试=======================
## 测试逻辑 :
## 对每种测试类型
## 对各种并发线程数
## 对指定的表个数
## 对不同表大小
## prepare
## sysbench 测试 ,默认测试1200秒
## cleanup
## ====================结束测试========================
一般测试类型选择oltp .
这个类型的事务一般包含如下的操作:
对于单个表执行 1.几个基于主键的查询;2.主键范围查找;3.主键范围查找+聚合函数;4.主键范围查找+文件排序;5.主键范围[……]
Read more
工作一直很忙, 已经好久没有去写点有新意的东西了.
原文标题是 “mysql基准测试模型以及percona 5.1对比mysql官方版本” , 这里修正下 ,计划发4篇
此篇是:mysql基准测试模型(1) 指引
—————————————-
以后新机器上线,可以先跑个脚本确保硬件基本满足需要了. 为什么很多人在新机器上线后不想做基准测试,无非是繁琐,耗时, 以及很难度量. 不是非常标准化的采购安装部署,主机总难免有些缺陷, 所以,如果有一个脚本,可以把cpu,磁盘,网络,数据库 都预先压测一遍,就可以省事多了.
我写下一些测试指引,方便大家构建 mysql的测试模型:
1. 当我们选择硬件的时候,我们需要考虑到各项成本,对于项目风险,开发成本,维护成本比较难以衡量,而计算机性能相对来说是更好限定和比较,所以考虑建立一个Mysql的基准测试模型;
2. 单个工具产品的基准测试,主要用于对比版本和衡量软硬件调整的效果,对于整个应用系统的测试没有什么参考意义,应用系统基准测试模型会比单个mysql测试模型更全民准确;[……]
Read more