MakoWorkload aims to measure the performance of FDB.
The primary purpose of this benchmark is to generate consistent performance results, in order to:

• Find performance regressions (release-to-release)
• Understand the maximum capability of an FDB cluster for a particular workload
• Understand the behavior of an FDB cluster with different configuration with the consistent workload
• Measure the impact of various cluster operations such as growing the cluster, shrinking the cluster, snapshot-backup, etc.

Report

• Throughput(overall)
• Latency(overall; per-operation, min / max / avg)
• Others(conflicts, retries, metrics related to data population)

Data Specification

• Key has a fixed prefix + sequential number + padding (e.g. Key1234567890xxxxxxxxxx)
• Value is just a random string of alphanumerics

Parameters

• rows: number of key-value pairs populated(Default: 10000)
• testDuration: test duration in seconds(Default: 30)
• keyBytes: key string length (Default and Minimum: 16)
• valueBytes: Maximum value string length (Default: 16)
• minValueBytes: Minimum value string length (Default: valueBytes)
• populateData: whether to generate k-v pairs and populate into database(Default: true)
• runBenchMark: whether to run benchmark to get metrics (Default: true)
• preserveData: whether to clean mako related data after running benchmark(Default: true)
• transactionsPerSecond: target total transaction-per-second(TPS) (Default: 100000/sec)
• actorCountPerClient: number of actors per tester(Default: 16)
• commitGet: if true, force commit for read-only transactions
• sampleSize: sampling rate (1 sample / sampleSize) for latency stats(Default: rows / 100)
• enableLogging: whether to have metrics each periodicLoggingInterval (Default: false)
• periodicLoggingInterval: time duration(sec) for each logging interval (Default: 5)
• operations: sequence of operations to run(Eg. "g90u10", see below for details)
• warmingDelay: wait for data distribution after data population(not work on a database with other users) (Default: 0)

Transaction Specification
A transaction may contain multiple operations of multiple types.
You can specify multiple operations for one operation type by specifying "Count".
For RANGE operations, "Range" needs to be specified in addition to "Count".
Every transaction is committed unless it contains only GET / GET RANGE operations.

Operation Types

• g – GET
• gr – GET RANGE
• sg – Snapshot GET
• sgr – Snapshot GET RANGE
• u – Update (= GET followed by SET)
• i – Insert (= SET with a new key)
• ir – Insert Range (Sequential)
• c – CLEAR
• sc – SET & CLEAR
• cr – CLEAR RANGE
• scr – SET & CLEAR RANGE
• grv – GetReadVersion()

Format
One operation type is defined as "<Type><Count>" or "<Type><Count>:<Range>".
When Count is omitted, it's equivalent to setting it to 1. (e.g. "g" is equivalent to "g1")
Multiple operation types can be concatenated. (e.g. "g9u1" = 9 GETs and 1 update)

Examples

• 100 GETs (No Commit)
  "g100"

• 10 GET RANGE with Range of 50 (No Commit)
  "gr10:50"

• 90 GETs and 10 Updates (Committed)
  "g90u10"

• 80 GETs, 10 Updates and 10 Inserts (Committed)
  "g90u10i10"