《高性能MySQL》读书笔记

第三版。

第二章

为什么需要基准测试

使用基准测试进行容量规划也要掌握技巧，不能只根据测试结果做简单的推断。例如，假设想知道使用新数据库服务器后，系统能够支撑多大的业务增长。首先对原系统进行基准测试，然后对新系统做测试，结果发现新系统可以支持原系统40 倍的TPS（每秒事务数），这时候就不能简单地推断说新系统一定可以支持40 倍的业务增长。这是因为在业务增长的同时，系统的流量、用户、数据以及不同数据之间的交互都在增长，它们不可能都有40 倍的支撑能力，尤其是相互之间的关系。而且当业务增长到40 倍时，应用本身的设计也可能已经随之改变。可能有更多的新特性会上线，其中某些特性可能对数据库造成的压力远大于原有功能。而这些压力、数据、关系和特性的变化都很难模拟，所以它们对系统的影响也很难评估。

结论就是，我们只能进行大概的测试，来确定系统大致的余量有多少。当然也可以做一些真实压力测试（和基准测试有区别），但在构造数据集和压力的时候要特别小心，而且这样就不再是基准测试了。基准测试要尽量简单直接，结果之间容易相互比较，成本低且易于执行。尽管有诸多限制，基准测试还是非常有用的（只要搞清楚测试的原理，并且了解如何分析结果所代表的意义）。

一个点的数量级的变化，整个系统的复杂和负载可能是不只一个数量级的变化，交互数据在增长、而且可能有新的业务加入、甚至应用本身的设计也在改变，而这一切，靠“评估”往往是不靠谱的。

但是，基准测试也不是万能的，基准测试往往是针对一个点的对比测试，整个系统的还是要进行基准测试的。

测试何种指标

响应时间

每次测试都可能得到不同的最大响应时间。因此，通常可以使用百分比响应时间来替代最大响应时间。例如，如果95%的响应时间都是5毫秒，则表示任务在95%的时间段内都可以在5毫秒内完成。

并发性

并发性基准测试需要关注的是正在工作中的并发操作，或者是同时工作中的线程或者连接数。

一般测试的时候，使用线程来进行模拟的，例如测试并发是5，会开5个线程，并发发出请求，当然，请求是同步的。

并发性的测量完全不同于响应时间和吞吐量。他不像是一个结果，而更像是设置了基准测试的一种属性。并发测试通常不是为了测试应用能达到的并发度，而是测试在不同并发下的性能。

扩展性

可扩展性指的是，给系统增加一倍的工作，在理想情况下就能获取两倍的结果（吞吐量增加一倍）。或者说给系统增加一倍的资源（比如两倍的CPU数），就可以获得两倍的吞吐量。

上面是理想的情况，一些简单的，限制条件比较单一的，或者扩展的时候是业务和数据集没变，所有硬件扩展，还是能做到的。如限制是IO的，比如Kafka，甚至只增加磁盘，就可以做到吞吐量线性扩展。还要一些分布式的系统，例如Mysql增加一个完全一样的副本，读的吞吐量也是可以做到的。但是如果系统内节点关系比较复杂，依赖的节点过多，做到线性扩展是比较困难的，比如MapReduce，增加的时候很少成倍的增加节点，如果只增加50%的数据，那么不要指望响应时间有50%的减少，或者吞吐量有50%的增加，因为涉及到了网络IO增加、物理机在机架的重新分布、region数据的大小和数目，很多因素影响。

常见错误

使用错误的数据分布。例如使用均匀分布的数据测试，而系统的真实数据有很多热点区域。

与真实用户行为不匹配。例如web页面中的“思考时间”。真实用户在请求收到一个页面后会阅读一段时间，而不是不停顿的一个接一个点击相关链接。

忽略了系统预热（warm up）的过程。

测试时间太短。

对于测试时间长短的问题，还有另外一段：

如果系统有大量的数据和内存，要达到稳定状态可能需要非常长的时间。大部分系统都有一些应对突发情况的余量，能够吸收性能尖峰，将一些工作延迟到高峰期之后执行。但当对机器加压足够长时间后，这些余量会被消耗尽，系统的短期尖峰也就无法维持原来的高性能。

有时无法确认系统运行多长时间才足够。如果是这样，可以让测试一直运行，持续观察直到确认系统已经稳定。

典型的，ES的field data并不是缓存，而是长期驻守在内存的，内存不够的时候会移除内存，如果测试时间段，而移除的过程和重新构建field data的过程，都是比较消耗资源的。如果仅进行几分钟的测试，那么这种情况是很难测试到这种情况的。而且ES还有不定期的段合并，也会对系统造成加大的波动。

书中给出的一个例子，在三个小时后，系统的IO才趋于稳定。

设计与规划基准测试

即使不需要创建标准基准测试，详细地写下测试规划也是必须的。测试可能需要多次反复运行，因此需要精确地重现测试过程。测试规划应该记录测试数据、系统配置的步骤、如何测量和分析结果，以及预热的方案等。

应该建立将参数和结果文档化的规范，每一轮测试都必须进行详细记录。文档规范可以很简单，比如采用电子表格或者记事本。

在执行基准测试的时候要尽可能地收集更多的细节数据，然后将数据绘制成图形，这样可以帮助快速地发现问题。