在开始执行甚至是在设计基准测试测试之前，需要先明确测试的目标。测试目标决定了选择什么样的测试工具和技术，以获得精确而有意义的测试结果。可以将测试目标细化为一系列的问题，比如，“这种CPU是否比另外一种要快?，”或“新索引是否比当前索引性能更好?
目标决定了选择
有时候需要用不同的测试方法测试不同的指标。比如，针对延迟(latency)和吞吐量(throughput)就需要采用不同的测试方法。
请考虑以下指标，看看如何满足测试的需求。
吞吐量
吞吐量指的是单位时间内的事务处理数。这一直是经典的数据库应用测试指标。 一些标准的基准测试被广泛地引用，如TPC-C，而且很多数据库厂商都努力争取在这些则试中取得好成绩。这类基准测试主要针对在线事务处理(OLTP)的存吐量，非常适用于多用户的交互式应用。常用的测试单位是每秒事务数(TPS),有些也采用每分钟事务数(TPM)。
响应时间或者延迟
这个指标用于测试任务所需的整体时间。根据具体的应用，测试的时间单位可能是微秒。毫秒或者分钟。根据不同的时间单位可以计算出平均响应时间、最小响应时间、最大响应时间和所占百分比。最大响应时间通常意义不大，因为测试时间越长，最大响应时间也可能越大。而且其结果通常不可重复，每次测试都可能得到不同的最大响应时间。因此，通常可以使用百分比响应时间(percentile responsetime)来替代最大响应时间。例如，如果95%的响应时间都是5毫秒，则表示任务在95%的时间段内都可以在5毫秒之内完成。
使用图表有助于理解测试结果。可以将测试结果绘制成折线图(比如平均值折线或者5%百分比折线)或者散点图，直观地表现数据结果集的分布情况。通过这些图可以发现长时间测试的趋势。本文后面将更详细地讨论这一点。
并发性
并发性是一个非常重要又经常被误解和误用的指标。例如，它经常被表示成多少用户在同一时间浏览一个Web站点，经常使用的指标是有多少个会话。然而，HTTP协议是无状态的，大多数用户只是简单地读取浏览器上显示的信息，这并不等同于Web服务器的并发性。而且，Web香港服务器的并发性也不等同于数据库的并发性，而仅仅只表示会话存诸机制可以处理多少数据的能力。Web香港服务器的并发性更准确的度量指标，应该是在任意时间有多少同时发生的并发请求。
在应用的不同环节都可以测量相应的并发性。Web 香港服务器的高并发，一般也会导致数据库的高并发，但香港服务器租用采用的语言和工具集对此都会有影响。注意不要将创建数据库连接和并发性搞混淆。一个设计良好的应用，同时可以打开成百上千个MySQL数据库香港服务器连接，但可能同时只有少数连接在执行查询。所以说，一个Web站点“同时有50 000个用户”访问，却可能只有10~ 15个并发请求到MySQL数据库。
换句话说，并发性基准测试需要关注的是正在工作中的并发操作，或者是同时工作中的线程数或者连接数。当并发性增加时，需要测量吞吐量是否下降，响应时间是否变长，如果是这样，应用可能就无法处理峰值压力。
并发性的测量完全不同于响应时间和吞吐量。它不像是一个结果， 而更像是设置基准测试的一种属性。 并发性测试通常不是为了测试应用能达到的并发度，而是为了测试应用在不同并发下的性能。当然，数据库的并发性还是需要测量的。可以通过sysbench指定32、64或者128个线程的测试，然后在测试期间记录MySQL数据库的Threads_ running 状态值。在后续将讨论这个指标对容量规划的影响。
可扩展性
在系统的业务压力可能发生变化的情况下，测试可扩展性就非常必要了。后面将更进一步讨论可扩展性的话题。简单地说，可扩展性指的是，给系统增加一倍的工作，在理想情况下就能获得两倍的结果(即吞吐量增加-倍)。或者说，给系统增加一倍的资源(比如两倍的CPU数)，就可以获得两倍的吞吐量。当然，同时性能(响应时间)也必须在可以接受的范围内。大多数系统是无法做到如此理想的线性扩展的。随着压力的变化，吞吐量和性能都可能越来越差。
可扩展性指标对于容量规范非常有用，它可以提供其他测试无法提供的信息，来帮助发现应用的瓶颈。比如，如果系统是基于单个用户的响应时间测试(这是一个很糟糕的测试策略)设计的，虽然测试的结果很好，但当并发度增加时，系统的性能有可能变得非常糟糕。而一个基于不断增加用户连接的情况下的响应时间测试则可以发现这个问题。
一些任务， 比如从细粒度数据创建汇总表的批量工作，需要的是周期性的快速响应时间。当然也可以测试这些任务纯粹的响应时间，但要注意考虑这些任务之间的相互影响。批量工作可能导致相互之间有影响的查询性能变差，反之亦然。
归根结底，应该测试那些对用户来说最重要的指标。因此应该尽可能地去收集一- 些需求,比如，什么样的响应时间是可以接受的，期待多少的并发性，等等。 然后基于这些需求来设计基准测试，避免目光短浅地只关注部分指标，而忽略其他指标。
