BenchmarkSQL Timed Driver

#BenchmarkSQL #Timed #Driver

1 背景知识

TPC-C 规范基于一个 3 层的模型。在此模型中，可以模拟多个终端同时向应用系统发起业务，这个应用系统称之为被测试系统SUT(System Under Test)。

SUT 实际上包含了应用（第二层）和数据库（第三层），模拟的终端可以测量响应时间。

虽然客户端时模拟出来的，但是仍然像人类一样需要一定的时间输入数据，并处理输出。

根据 TPC-C 规范，客户端收到输出结果后至少等待 21 秒之后才能够发出下一个请求。请求的间隔并不是固定在 21 秒的。实际的等待时间由事务类型和一些随机因素。

BenchMarksql 6.0 尽可能接近 TPC-C 工作负载的风格。BenchMarksql 6.0 专注于数据库性能。所以 BenchMarksql 6.0 在工具中实现了第一层和第二层。同时还能测量第一层的响应时间。

TPC-C 定义了缩放规范。测试的数据量由仓库数量定义。大多数据表（Item 表除外）大小和仓库数量成正比。目前一个仓库的磁盘数据量约为 100MB 。

缩放的因子参数还定义了要模拟的客户端数量，每个客户端生成的最大交易请求数。

TPC-C 规定每个仓库必须有 10 个客户端。每个客户端收到结果到发送下一个事务的间隔大约为 21 秒。

根据以上规则：每个线程一个客户端“的实现很可能出现以下的问题。

如果我们要生成一个 100GB 的数据库，我们需要配置 1,000 个仓库。这将产生 10,000 个终端线程。在 CentOS-7 64bit 这样的操作系统上，每个线程默认使用 1MB 堆栈空间和上下文在 10,000 个线程之间切换，将导致 CPU 非常繁忙。

当生成 1TB 数据库时，整个系统将会崩溃。

为了避免 TPC-C 中导致客户端数量过多带来的性能崩溃问题，BenchMarksql 6.0 中的客户端不是一个线程，而是多线程架构。

TData 对象主要是指客户端的输入数据和输出数据，并包含相应时间和控制计划的时间戳等信息。

BenchMarksql 6.0 不是通过每个客户端进程来模拟人类的操作。而是配置 训练有素的猴子 模拟人类。可以想象成一个猴子从一个客户端跳到另外的客户端快速操作，具体的流程如下：

根据这种设计架构，只需要少量的 Monkey 线程可以模拟成千上万的客户端。

不过，很有可能由于客户端数量太多，导致 Monkey 线程无法及时输入新事务。这种情况下，请配置更多的 Monkey 线程以解决这个问题。

调度器用于管理 TData 对象的一个进程，TData 对象为 Monkey 线程提供输入的数据。TData 对象使用 AVL 树结构进行组织。

Scheduler 的作用就是将 TData 准时的发送给 Monkey 线程，除此之外没有任何其他用途。

将 TData 发送给应用系统的时间就是客户端应该按下发送按钮的时间。也是计量响应时间的开始时间。

SUT 是由 FIFO 队列和若干 SUT 线程组成的。SUT 用于模拟应用程序连接到数据库的连接。每个SUT线程只能使用自己的数据库链接进行事务处理。

配置SUT 线程的数量要根据硬件条件配置：

SUT 线程从 FIFO 队列中挑选下一个 TData ，处理对应请求的事务，并将输出数据j结果填入 TData 对象，并记录事务结束时间。

此时用户事务响应结束，输出结果展示在了终端上。

有时 SUT 线程处理事务的速度较慢，会导致 FIFO 队列中数据积压。当 [[#3 TData]] 在队列中进行等待时，这段时间会被记录成响应时间。这样能够真实模拟用户等待的真实时间。

Delivery 在 TPC-C 规范中是独一无二的。

Delivery 有一个前台部分，用于客户端于SUT 通信，用于将交付请求进行队列，并把已经排队的信息提交给客户端。
这种请求操作会放在后台进行。处理时间较为宽松，因为操作会占用大量的IO 。 TPC-C 并没有规定如何实现队列机制，而是让用户自行决定，不过仍然有一个要求： 90% Delivery 后台请求都必须要在Delivery 的前台部分完成之后 85 秒完成。

当 SUT 线程和Delivery前台部分交互时，它会创建一个 TData 对象，并将其发送给 Delivery BG Scheduler。填入合适的信息之后发送给 Monkey sequence 。

Delivery BG Scheduler 有一个监控之下的队列。 BenchMarksql 6.0 有一个配置选项，限制 Delivery BG Scheduler 发送给SUT 线程的请求数。这是为了避免数据库长时间忙于处理事务。从而忽略了真正那些紧急的请求。