$ ./bin/ycsb load basic -P workloads/workloada -P large.dat -s > load.dat
Loading workload... (might take a few minutes in some cases for large data sets)
Starting test.
0 sec: 0 operations
10 sec: 61731 operations; 6170.6317473010795 operations/sec
20 sec: 129054 operations; 6450.76477056883 operations/sec
...
这个状态输出会帮助你看到加载操作执行得多快（这样你可以估计加载的完成时间），确认load正在执行。当load完成时，Client会报告load的性能统计数据。这些统计与transaction阶段一样，所以看后续介绍
Step 6 执行workload一旦数据被加载，你就可以执行workload。告诉Client执行transaction操作。执行workload，可以使用以下命令
$ ./bin/ycsb run basic -P workloads/workloada -P large.dat -s > transactions.dat
主要差别是我们使用run参数时，告诉Client执行transaction阶段而不是loading阶段。如果你使用BasicDB，检查结果文件 transactions.dat，你会看到一个read和update混合的请求，与统计数据一致。
典型情况下，你会希望使用 -threads 和 -target 参数控制负荷量。例如，你可能希望10个线程每秒总数100个操作。平均操作延时不高于100ms，每个线程能够携带每秒10此操作。一般来说，你需要足够的线程因为没有线程尝试每秒更多的操作，否则你达到的吞吐量将小于指定的目标吞吐量。
这个例子，我们可以执行
$ ./bin/ycsb run basic -P workloads/workloada -P large.dat -s -threads 10 -target 100 > transactions.dat
注意这个例子，我们使用 -threads 10 命令参数指定10个线程， -target 100 命令参数指定每秒100次操作。否则，两个值可以设置在你的参数文件中，使用threadcount 和 target 属性代替。例如
threadcount=10
target=100
run的结尾，Client会向stdout报告性能统计数据。上面的例子，统计数据会写入transaction.dat文件。默认包括每个操作类型延时的average,min,max,95th,99th。每次操作返回代码的统计，每类操作的直方图。返回值被你的DB接口层定义，允许你看到workload过程中的任何错误。上述例子中，我们可以得到输出：
[OVERALL],RunTime(ms), 10110
[OVERALL],Throughput(ops/sec), 98.91196834817013
[UPDATE], Operations, 491
[UPDATE], AverageLatency(ms), 0.054989816700611
[UPDATE], MinLatency(ms), 0
[UPDATE], MaxLatency(ms), 1
[UPDATE], 95thPercentileLatency(ms), 1
[UPDATE], 99thPercentileLatency(ms), 1
[UPDATE], Return=0, 491
[UPDATE], 0, 464
[UPDATE], 1, 27
[UPDATE], 2, 0
[UPDATE], 3, 0
[UPDATE], 4, 0
...
这个输出指标
总体执行时间为10.11秒
平均吞吐量98.9 ops（所有线程）
491次修改操作，附带average,min,max,95th,99th %延迟情况
所有491次修改操作都返回0（成功）
464次操作在1ms内完成，27次在1至2ms内完成。
读操作有与之接近的统计数值
延时信息的直方图通常是有用的，时序图的形式有时更有用。请求一个时序，需要在Client命令行或在属性文件指定"measureenttype=timeseries"属性。默认情况下，Client会每间隔1000ms，报告一次平均延时。你可以对报告指定不同的间隔粒度，使用 timeseries.granularity属性，例如。
$ ./bin/ycsb run basic -P workloads/workloada -P large.dat -s -threads 10 -target 100 -p \measurementtype=timeseries -p timeseries.granularity=2000 > transactions.dat
将会报告一个时序，间隔2000ms读一次，结果将是。
[OVERALL],RunTime(ms), 10077
[OVERALL],Throughput(ops/sec), 9923.58836955443
[UPDATE], Operations, 50396
[UPDATE], AverageLatency(ms), 0.04339630129375347
[UPDATE], MinLatency(ms), 0
[UPDATE], MaxLatency(ms), 338
[UPDATE], Return=0, 50396
[UPDATE], 0, 0.10264765784114054
[UPDATE], 2000, 0.026989343690867442
[UPDATE], 4000, 0.0352882703777336
[UPDATE], 6000, 0.004238958990536277
[UPDATE], 8000, 0.052813085033008175
[UPDATE], 10000, 0.0
[READ], Operations, 49604
[READ], AverageLatency(ms), 0.038242883638416256
[READ], MinLatency(ms), 0
[READ], MaxLatency(ms), 230
[READ], Return=0, 49604
[READ], 0, 0.08997245741099663
[READ], 2000, 0.02207505518763797
[READ], 4000, 0.03188493260913297
[READ], 6000, 0.004869141813755326
[READ], 8000, 0.04355329949238579
[READ], 10000, 0.005405405405405406
这个输出分开显示了update和read操作的时间序列，每2000ms的数据。数据报告的时点是仅包括前一个2000ms的均值。（这个例子，我们做了100,000次操作，目标是每秒10,000次操作）。一个关于延时度量的关注点：Client度量，特定操作对数据库的端到端的执行延时。那样，它在调用DB接口层class适当方法前会启动启动一个时钟，方法返回时会停止时钟。延时包括：执行包括接口层，到数据库服务器的网络延迟，数据库的执行时间。不包括用于控制吞吐量的延迟。就是说，如果你指定目标是每秒10次操作（单线程）Client会在每100ms仅执行1次操作。如果操作耗费了12ms，Client会在下一次操作前额外等待88ms。然而，报告延时不会包括这个等待时间，报告会显示延迟是12ms而不是100.