11.性能基准

11.1 性能基准

11.1.1 了解基准测试

基准测试是用于评估系统性能的常用手段,对容量的规划以及成本的评估有重要意义! 通常，基准测试需要在一种相对确定的系统配置和环境（包括工作负载）中展开测试，在此过程中对产生的结果进行收集、分析以及评估，并以此建立可度量的参考标准。基准测试方法需要满足3个基本原则。

• 可重复性，指测试过程可以反复进行，对于同样过程产生的结果应该是稳定的，不会受到时间、地点、执行者的影响。
• 可度量性，指测试产生的结果可以进行量化，一次基准测试的结果通常会涉及多种数据指标。
• 可对比性，可基于不同的系统配置或环境条件进行多组测试，比较每次测试的结果，为系统调优和规划工作提供评估参考。

在当前主流的WEB架构中,数据库一直是非常关键的位置,由此可见，提前对数据库进行基准测试这项工作就变得非常重要了。通过对业务数据库开展基准测试，我们可以从以下几个方面获得受益。

• 应用层优化，对于不同的数据库设计模式（schema），是选择内嵌还是拆表，可能导致较大的性能差异。通过基准测试可以识别一些问题，并帮助我们确定最佳模式。
• 数据库优化，对系统的某些特定配置进行调优之后，或是采用不同的数据库版本、硬件环境进行对比测试，以此论证系统调优所带来的成本缩减。
• 容量规划，基于业务需求（包含读写比例、数据集的大小等）和现有的数据库配置规格进行基准负载测试，建立数据库性能基线，为系统在未来的容量发展规划提供可信的依据。

11.1.2 吞吐量、并发数、响应时间

• 响应时间：客户端从发出请求开始，到返回响应所需要的时长。响应时间的指标包含平均响应时间、最短响应时间、最长响应时间，以及时间百分比指标。
• 吞吐量（TPS/QPS）：数据库每秒处理的事务数。一个事务对一次请求响应的过程。
• 并发数：同一时间点请求服务器的用户数，一般是通过建立并发连接或线程进行模拟。

在服务器没有达到瓶颈的情况下，这3个指标的关系如下：吞吐量=并发数/响应时间

图中说明了这几项指标的一些关系。在并发数达到一定的数量后，系统的吞吐量开始呈现平稳的趋势，当压力持续增大并超过系统负荷之后，吞吐量反而会下降，此时通常也伴随着响应时间的延长而明显增大。

11.2 WiredTiger读写模型

11.2.1 读缓存

WiredTiger引擎实现了数据的二级缓存，第一层是操作系统的页面缓存，第二层则是引擎提供的内部缓存

• 读取数据
  • 数据库发起Buffer I/O读操作，由操作系统将磁盘数据页加载到文件系统的页缓存区。
  • 引擎层读取页缓存区的数据，进行解压后存放到内部缓存区。
  • 在内存中完成匹配查询，将结果返回给应用。

可以看出，如果数据已经被存储在内部缓存中，MongoDB则可以发挥最佳的读性能。稍差的情况是内部缓存中找不到，但数据仍然被存储在操作系统的页缓存中，此时需要花费一些数据解压缩的开销。直接从磁盘加载数据的性能是最差的，因此MongoDB为了尽可能保证业务查询的“热数据”能快速被访问，其内部缓存的默认大小达到了内存的一半，该值由wiredTigerCacheSize参数指定，其默认的计算公式如下：
wiredTigerCacheSize=Math.max((RAM-1GB),256MB)

11.2.2 写缓冲

当数据发生写入时，MongoDB并不会立即持久化到磁盘上，而是先在内存中记录这些变更，之后通过CheckPoint机制将变化的数据写入磁盘。

• 如果每次写入都触发一次磁盘I/O，那么开销太大，而且响应时延会比较大。
• 多个变更的写入可以尽可能进行I/O合并，降低资源负荷。

这样做虽然有很大优点:但是数据一旦被持久化,就避不开另外一个问题:可靠性

MongoDB单机下保证数据可靠性的机制包括以下两个部分。

（1）CheckPoint（检查点）机制：快照（snapshot）描述了某一时刻（point-in-time）数据在内存中的一致性视图，而这种数据的一致性是WiredTiger通过MVCC（多版本并发控制）实现的。当建立CheckPoint时，WiredTiger会在内存中建立所有数据的一致性快照，并将该快照覆盖的所有数据变化一并进行持久化（fsync）。成功之后，内存中数据的修改才得以真正保存。默认情况下，MongoDB每60s建立一次CheckPoint，在检查点写入过程中，上一个检查点仍然是可用的。这样可以保证一旦出错，MongoDB仍然能恢复到上一个检查点。
（2）Journal日志：Journal是一种预写式日志（write ahead log）机制，主要用来弥补CheckPoint机制的不足。如果开启了Journal日志，那么WiredTiger会将每个写操作的redo日志写入Journal缓冲区，该缓冲区会频繁地将日志持久化到磁盘上。默认情况下，Journal缓冲区每100ms执行一次持久化。此外，Journal日志达到100MB，或是应用程序指定journal：true，写操作都会触发日志的持久化。一旦MongoDB发生宕机，重启程序时会先恢复到上一个检查点，然后根据Journal日志恢复增量的变化。由于Journal日志持久化的间隔非常短，数据能得到更高的保障，如果按照当前版本的默认配置，则其在断电情况下最多会丢失100ms的写入数据。

原文地址：http://www.cnblogs.com/cdlszl/p/16821609.html