发现瓶颈 - 基准测试的策略

基准测试的策略

有两个主要的基准测试策略：可以把对一个整体的应用做基准测试，或者就是对单独的MySQL做基准测试。这两种一般被成为“全栈式full-stack”和“单独组件single-component”的基准测试。对整个应用的基准测试好于单独的对MySQL。原因如下

 

• 你测试整个应用，包括了web服务器，程序代码，数据库。你不用单独的考虑MySQL的性能。你关心的是整个应用。
• MySQL并不总是应用的瓶颈。全栈的基准测试可以发现瓶颈。
• 只有全栈的测试，才能看出来每部分的缓存的行为。
• 基准测试能反映出应用实际的表现，但是当你测试一部分就很难做到了。

换句话说，基于应用的基准测试可能会非常难创建以及甚至更难去正确的准备。如果基准设计的很烂，你可能会做错误的决定。因为结果本身就不是真实的。

有的时候，你可能不需要了解整个应用。至少在最初阶段，你可能仅仅需要MySQL的基准测试。在下列的条件下，这种基准测试比较有用：

• 你要比较不同的数据模型或语句。
• 在应用中，你想针对某个问题做基准测试。
• 你要避免长期的基准测试，用短期的基准测试来使你短期内快速更该和估算一些修改。

当你重复使用应用程序的应用于真实的数据，对于MySQL的基准测试也非常有用。数据本身和数据集的大小需要是真实的。如果可能，请使用真实数据的拷贝。

不幸的是，设置真实的基准测试可能有些复杂和消耗时间。如果你得到了产品数据集的拷贝，你应该感到幸运。。当然，这还是有可能的。如，你可能开发一个很少用户量和数据的应用。如果你想知道随着数据的增长，这个应用的表现如何，你可能没有什么选择，但是可以模拟大量的应用数据和负荷。

测量些什么？

你在开始基准测试之前，需要知道你的目标-其实是在你设计基准测试之前。你的目标要决定使用哪种工具和技术能使你获得准确的有意义的结果。用问题来构建你的目标，如“这个CPU好于那一个么？”或者这个新的索引好于当前的那个么？“

 

这可能不是显而易见的，但是你有的时候需要不同的方法测量不同的指标。如，延迟和吞吐量可能需要不同的基准测试。

 

考虑下面的一些测量以及它们怎样适用于你的性能目标。

 

每单位时间内的事物处理次数（Transactions per time unit）

对于数据库应用的基准测试，它总是经典之一。标准的基准测试如TPC-C广泛引用它们，以及许多数据库厂商都致力于让它们工作的更好。这些基准测试测量了事物处理（OLTP）性能以及最适合的多用户交互程序。这个测量单位通常是没秒的事物处理次数（transactions per second.）

 

响应时间或延迟（Response time or latency）

它测量了一个任务需要的总时间。测量单位可能是毫秒，秒，或者分，这取决于你的应用。通过这些，你可以得到最小和最大响应时间。

 

最大响应时间是是很少使用的度量。因为基准测试运行多久，最大响应时间也大概是多少。也没有必要重复测量，因为运行之中，它变化特别大。所以，许多用户使用百分数响应时间（percentile response times）。一个例子，如果在95%的响应时间都在5ms之内，你能了解到，这个任务完成时间，有95%的机率小于5毫秒。

 

把结果图形化比较适合这个基准测试。可以使用线图或者散布图，使你可以知道结果是如何分布的。这些图表可以在很长的运行时间，这个基准测试是怎样表现的。

 

假如你的系统在每隔一小时一分钟都会有个检查点。在这个检查点期间，系统就停止了以及没有事物完成。95%的响应时间不会显示在图上。因此结果隐藏了一些错误。然而，图会周期性显示的。如图

 

 

可伸缩性（Scalability）

可伸缩性对于那些在负荷变化的情况下，要求保持性能的系统尤其重要。”在负荷变化的情况下的性能”这句话是个完全抽象的概念。性能一般来说都是由吞吐量或者响应时间来测量的。以及伴随着数据库大小的变化，并发数链接或者硬件，系统负荷也是变化非常大的。

 

可伸缩性的对于系统能力的测量是非常有益的。因为它们能显示在应用中的弱点，而其他基准测试的策略却做不到。一个例子，如果你设计的系统在单连接的情况下，基准测试的响应时间非常不错。当在任意级别的并发数下，你的应用可能表现就很差了。在持续增加并发的情况下，查看系统持续响应时间的这个基准测试，可以显示出系统的设计缺陷。

 

并发性（Concurrency）

并发性很重要，但是常常被人错误的使用和理解的一个度量。比如，流行的说法是同一时间内，有多少用户访问一个网站。然而 HTTP是无状态的以及大部分用户都简单的阅读显示在浏览器中的内容。因此，就不能把这种情形称为web服务器的并发性。同样的web服务器的并发性也不能认为是数据库的并发性。唯一相关的就是你的会话存储机制（session storage mechanism）允许处理多少数据量。一个关于更准确的在服务器上的并发性是，在高峰期用户产生的每秒有多少请求数（how many requests per second）。

 

在应用中，可以在许多地方测量并发性。web服务器的高并发可以导致数据库的高并发，但是计算机语言和工具集会影响这些。如，java的连接池比php持久连接有更低的并发连接数。

 

更重要的是在给定的时间内运行语句的那些连接数。一个设计优秀的应用可能对MySQL只有几百个连接，但是同时只有一小部分的连接运行语句。因此，一个同时“在线5000用户”的网站可能在MySQL上只需要同时运行10或者15个语句。

 

换句话说，你真正所关心的基准测试是工作时的并发（working concurrency）或者是线程数或者是同时工作的连接。

当并发提高的时候，测量性能是否下降很多。如果性能下降，就说明你的应用不能在峰值下进行处理。

 

你需要确定要么性能不是下降的很厉害，要么设计的应用的部分不满足高并发性。一般来说，你想限制MySQL的并发性。可以查看以后的章节。

 

并发性是和响应时间和可伸缩性完全不一样。它不是个结果，但是是一个怎样准备基准测试的属性（property）。你在不同的级别的并发性测量程序的性能，替代测量应用完成的并发性。

 

在最后的分析，你应该对用户重要的任意的因素进行基准测试。基准测试测量了性能，但是性能对不同的人来说，是不同的东西。收集一些关于系统伸缩的需求，以及可允许的响应时间，还有期望并发性的种类等等。之后尝试设计对于所有需求的基准测试，不要视野太狭隘以及关注其他一些额外的东西。