前言

主要策略：

  • 集成式（full-stack）：针对整个系统的整体测试
  • 单组件式（single-component）：单独测试 MySQL

针对整个系统做集成式测试的主要原因有：

  • 测试整个应用系统，包括 Web 服务器、应用代码、网络和数据库是非常有用的；毕竟用户使用不仅仅是 MySQL 的性能，而是整体性能；
  • MySQL 并非总是应用的瓶颈，通过整体测试可确认这点；
  • 只有整体测试，才能发现各部分之间的缓存带来的影响；
  • 整体测试更能确定应用的真实表现。

以下情况可考虑只针对 MySQL 做测试：

  • 需要比较不同的 schema 或查询的性能；
  • 针对应用中某个具体问题的测试；
  • 为避免漫长的基准测试，通过短期的测试，做快速的“周期循环”，来检测某些调整后的效果。

另如果能够在真实的数据集上执行重复的查询，也是有用的。如果可能，可采用生产环境的数据快照。

测试何种指标

吞吐量

  • 吞吐量是指单位时间内的事务处理数。
  • 常用的测试单位：每秒事务数（TPS）；有些也采用每分钟事务数（TPM）

响应时间或延迟

  • 用于测试任务所需的整体时间。单位可能是：微秒、毫秒、秒或者分钟。
  • 根据不同的时间单位可计算出：平均响应时间、最小响应时间、最大响应时间和所占百分比。
    • 最大响应时间一般参考意义不大，因为测试时间越长，响应时间也越大；
  • 通常可使用百分比响应时间（percentile response time）来替代最大响应时间。
    • 例如：95% 的响应时间都是 5 毫秒，则表示任务在 95% 的时间段里可在 5 毫秒内完成。
  • 可使用图表有助于理解，如折线图、散点图等。

并发性

误区：Web 的并发性不等同于数据库的并发性，而仅仅表示会话存储可以处理多少数据的能力。 Web 服务器的并发性更准确的度量标准是：在任意时间有多少同时发生的并发请求。

  • 一般网络应用里，Web 服务器的高并发也会导致数据库的高并发。
  • 并发性基准测试需要关注：当并发数增加时，吞吐量是否下降，相应时间是否变长。如果是这样，则无法处理峰值压力。
  • 并发性的测量无法想吞吐量和响应时间，是一个具体的结果，更像是设置基准测试的一种属性。
  • 可通过 sysbench 指定 32、64 或者 128 个线程的测试，然后记录 MySQL 的 Threads_running 的状态值。

可扩展性

  • 可扩展性是指：给系统增加一倍的工作，在理想情况下就能获得两倍的结果（即吞吐量增加一倍）。或者说给系统增加一倍的资源（如：两倍的 CPU 数），就可获得两倍的吞吐量。
  • 大多数系统无法做到如此理想的线性扩展，随着压力变大，吞吐量和性能都可能越来越差。