《高性能MySQL》第二章读书笔记

MySQL基准测试

 

基准测试的用途：

• 验证基于系统的一种假设
• 重现系统中的某些异常行为，以解决这些异常
• 测试系统当前的运行情况
• 模拟比当前系统更高的负载，以找出瓶颈
• 规划未来的业务增长
• 测试应用适应可变环境的能力
• 测试不同的硬件、软件和操作系统配置
• 证明新采购的设备是否配置正确

 

基准测试的策略

 

基准测试有两种主要的策略：一个是针对系统的整体测试，另外是单独测试。这两种策略也被称为集成式以及单组件基准测试。

 

整体测试的原因

 

·测试整个应用系统，包括Web服务器、应用代码、网络和数据库是非常有用的，因为用户关注的并不仅仅是MySQL本身的性能，而是应用整体的性能。

·MySQL并非总是应用的瓶颈，通过整体的测试可以揭露这一点。

·只有对应用做整体测试，才能发现各部分之间的缓存带来的影响。

·整体应用的集成式测试更能揭示应用的真是表现，而单独组件的测试很难做到这一点。

 

单独测试MySQL的原因

 

·需要比较不同的schema或查询的性能

·针对应用中某个具体问题的测试

·为了避免漫长的基准测试，可以通过一个短期的基准测试，做快速的“周期循环”，来检测出某些调整后的效果

 

基准测试的指标

 

吞吐量

         吞吐量指的是单位时间内的事务处理数。这一直是经典的数据库应用测试指标。一些标准的基准测试被广泛使用。这类基准测试主要针对在线事务处理（OLTP）的吞吐量，非常适用于多用户的交互式应用。常用的测试单位是每秒事务数（TPS）。

响应时间或者延迟

         这个指标用于测试任务所需的整体时间。根据具体的应用，测试的时间单位可能是微秒、毫秒、秒或者分钟。通常用响应时间比来代替最大响应时间。

并发性

         并发性是一个非常重要又经常被误解的指标。Web服务器的并发性更准确的度量指标，应该是在任意时间有多少同时发生的并发请求。一个设计良好的应用，同时打开成百上千个MySQL数据库服务连接，但可能同时只有少数连接在执行查询。

可拓展性

         在系统的业务压力可能变化的情况下，测试可拓展性就非常必要了。可拓展性指的是给系统增加一倍的工作，在理想情况下就能获得两倍的结果。

 

基准测试方法

 

如何避免一些常见的错误，这些错误可能导致测试结果无用或者不精确：

·使用真实数据的子集而不是全集。例如应用需要处理几百GB的数据，但测试只有1GB的数据；或者只使用当前数据进行测试，却希望模拟未来业务大幅度增长后的情况。

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

·使用不真实的分布参数，例如假定所有用户的个人信息都会被平均地读取。

·在多用户场景中，只做单用户的测试。

·在单服务器上测试分布式应用。

·与真实用户行为不匹配。真实用户在请求到一个页面后会阅读一段时间，而不是不停顿

地一个接一个地点击相关链接。

·反复执行同一个查询。真实的查询是不尽相同的，这可能会导致缓存命中率降低。

·没有检查错误

·忽略了系统预热的过程。

·使用默认的服务器配置

·测试的时间太短

 

 

 

设计和规划基准测试

 

规划基准测试的第一步就是提出问题并明确目标。然后决定是采用标准的基准测试，还是设计专用的测试。如果采用标准的基准测试，应该确认选择了合适的测试方案。设计一个专用的基准测试是很复杂的，往往需要一个迭代的过程。首先需要获得生产数据集的快照，并且该快照很容易还原，以便进行后续的测试。测试规划应该记录下测试数据、系统配置的步骤、如何测量和分析结果，以及预热的方案等。应该建立将参数和结果文档化的规范，每一轮测试都必须进行详细记录

 

 

 

基准测试应该运行多长的时间

 

基准测试应该运行足够长的时间，这一点很重要。如果需要测试系统在稳定状态时间的性能，那么当然需要在稳定状态下测试并观察。而如果系统有大量的数据和内存，要达到这个稳定状态可能需要非常长的时间。大部分系统都会有一些应对突发情况的余量，能够吸收性能尖峰，将一些工作延迟到高峰期之后执行。

 

获取系统性能和状态

 

在执行基础测试时，需要尽可能多地收集被测试系统的信息。最好为基准测试建立一个目录，并且每执行一轮测试都要创建单独的子目录，将测试结果、配置文件、测试指标、脚本和其他相关说明都保存其中

 

获得准确的测试结果

 

获得测试结构结果最好的方法，是回答一些关于基准测试的基本问题：是否选择了正确的基准测试？是否为问题收集了相关的数据？是否采用了错误的测试标准？接着确认测试结果是否重复。每次测试中，修改的参数应该尽量少。如果必须要一次修改多个参数那么可能会丢失一些信息。有些参数依赖于其他的参数，这些参数可能无法单独修改。

 

运行基准测试并分析结果

 

一单准备就绪，就可以着手基准测试，收集和分析数据了。自动化基础测试是一个好主意，这样做可以获得更精确的测试结果，因为自动化的过程可以防止测试人员偶尔遗漏某些步骤，或者误操作。自动化的方式有很多，可以说Makefile文件或者一组脚本。Shell、 PHP、 Perl都可以。尽可能地使所有的测试过程都自动化，包括装载数据、系统预热、执行测试、记录结果等。

 

基准测试工具

 

集成式测试工具

 

ab

         ab是一个HTTP服务器测试工具。他可以测试HTTP服务器每秒最多可以处理多少请求。这是个非常简单的工具，只能针对单个URL进行尽可能快的压力测试。

http_load

         这个工具概念上和ab类似，但比ab更灵活，可以在URL随机测试。

JMeter

         是一个Java应用程序，可以加载其他应用并测试其性能。

MySQL基准测试

 

基准测试的用途：

• 验证基于系统的一种假设
• 重现系统中的某些异常行为，以解决这些异常
• 测试系统当前的运行情况
• 模拟比当前系统更高的负载，以找出瓶颈
• 规划未来的业务增长
• 测试应用适应可变环境的能力
• 测试不同的硬件、软件和操作系统配置
• 证明新采购的设备是否配置正确

 

基准测试的策略

 

基准测试有两种主要的策略：一个是针对系统的整体测试，另外是单独测试。这两种策略也被称为集成式以及单组件基准测试。

 

整体测试的原因

 

·测试整个应用系统，包括Web服务器、应用代码、网络和数据库是非常有用的，因为用户关注的并不仅仅是MySQL本身的性能，而是应用整体的性能。

·MySQL并非总是应用的瓶颈，通过整体的测试可以揭露这一点。

·只有对应用做整体测试，才能发现各部分之间的缓存带来的影响。

·整体应用的集成式测试更能揭示应用的真是表现，而单独组件的测试很难做到这一点。

 

单独测试MySQL的原因

 

·需要比较不同的schema或查询的性能

·针对应用中某个具体问题的测试

·为了避免漫长的基准测试，可以通过一个短期的基准测试，做快速的“周期循环”，来检测出某些调整后的效果

 

基准测试的指标

 

吞吐量

         吞吐量指的是单位时间内的事务处理数。这一直是经典的数据库应用测试指标。一些标准的基准测试被广泛使用。这类基准测试主要针对在线事务处理（OLTP）的吞吐量，非常适用于多用户的交互式应用。常用的测试单位是每秒事务数（TPS）。

响应时间或者延迟

         这个指标用于测试任务所需的整体时间。根据具体的应用，测试的时间单位可能是微秒、毫秒、秒或者分钟。通常用响应时间比来代替最大响应时间。

并发性

         并发性是一个非常重要又经常被误解的指标。Web服务器的并发性更准确的度量指标，应该是在任意时间有多少同时发生的并发请求。一个设计良好的应用，同时打开成百上千个MySQL数据库服务连接，但可能同时只有少数连接在执行查询。

可拓展性

         在系统的业务压力可能变化的情况下，测试可拓展性就非常必要了。可拓展性指的是给系统增加一倍的工作，在理想情况下就能获得两倍的结果。

 

基准测试方法

 

如何避免一些常见的错误，这些错误可能导致测试结果无用或者不精确：

·使用真实数据的子集而不是全集。例如应用需要处理几百GB的数据，但测试只有1GB的数据；或者只使用当前数据进行测试，却希望模拟未来业务大幅度增长后的情况。

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

·使用不真实的分布参数，例如假定所有用户的个人信息都会被平均地读取。

·在多用户场景中，只做单用户的测试。

·在单服务器上测试分布式应用。

·与真实用户行为不匹配。真实用户在请求到一个页面后会阅读一段时间，而不是不停顿

地一个接一个地点击相关链接。

·反复执行同一个查询。真实的查询是不尽相同的，这可能会导致缓存命中率降低。

·没有检查错误

·忽略了系统预热的过程。

·使用默认的服务器配置

·测试的时间太短

 

 

 

设计和规划基准测试

 

规划基准测试的第一步就是提出问题并明确目标。然后决定是采用标准的基准测试，还是设计专用的测试。如果采用标准的基准测试，应该确认选择了合适的测试方案。设计一个专用的基准测试是很复杂的，往往需要一个迭代的过程。首先需要获得生产数据集的快照，并且该快照很容易还原，以便进行后续的测试。测试规划应该记录下测试数据、系统配置的步骤、如何测量和分析结果，以及预热的方案等。应该建立将参数和结果文档化的规范，每一轮测试都必须进行详细记录

 

 

 

基准测试应该运行多长的时间

 

基准测试应该运行足够长的时间，这一点很重要。如果需要测试系统在稳定状态时间的性能，那么当然需要在稳定状态下测试并观察。而如果系统有大量的数据和内存，要达到这个稳定状态可能需要非常长的时间。大部分系统都会有一些应对突发情况的余量，能够吸收性能尖峰，将一些工作延迟到高峰期之后执行。

 

获取系统性能和状态

 

在执行基础测试时，需要尽可能多地收集被测试系统的信息。最好为基准测试建立一个目录，并且每执行一轮测试都要创建单独的子目录，将测试结果、配置文件、测试指标、脚本和其他相关说明都保存其中

 

获得准确的测试结果

 

获得测试结构结果最好的方法，是回答一些关于基准测试的基本问题：是否选择了正确的基准测试？是否为问题收集了相关的数据？是否采用了错误的测试标准？接着确认测试结果是否重复。每次测试中，修改的参数应该尽量少。如果必须要一次修改多个参数那么可能会丢失一些信息。有些参数依赖于其他的参数，这些参数可能无法单独修改。

 

运行基准测试并分析结果

 

一单准备就绪，就可以着手基准测试，收集和分析数据了。自动化基础测试是一个好主意，这样做可以获得更精确的测试结果，因为自动化的过程可以防止测试人员偶尔遗漏某些步骤，或者误操作。自动化的方式有很多，可以说Makefile文件或者一组脚本。Shell、 PHP、 Perl都可以。尽可能地使所有的测试过程都自动化，包括装载数据、系统预热、执行测试、记录结果等。

 

基准测试工具

 

集成式测试工具

 

ab

         ab是一个HTTP服务器测试工具。他可以测试HTTP服务器每秒最多可以处理多少请求。这是个非常简单的工具，只能针对单个URL进行尽可能快的压力测试。

http_load

         这个工具概念上和ab类似，但比ab更灵活，可以在URL随机测试。

JMeter

         是一个Java应用程序，可以加载其他应用并测试其性能。