响应时间或延迟（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）。你在不同的级别的并发性测量程序的性能，替代测量应用完成的并发性。

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