Storage Benchmark Kit SBK

Build Status License Api Version CII Best Practices

Any Storage SystemAny PayloadAny Time Stamp

The SBK (Storage Benchmark Kit) is an open source software frame-work for the performance benchmarking of any storage system. If you are curious to measure the maximum throughput performance of your storage device/system, then SBK is the right software for you. The SBK itself a very high-performance benchmark tool/framework. It massively writes the data to storage system and reads the data from storage system. The SBK supports multi writers and readers and also the End to End latency benchmarking. The percentiles are calculated for complete data written/read without any sampling; hence the percentiles are 100% accurate.


Supported By

Jet Brains


The design principle of SBK is the Performance Benchmarking of ‘Any Storage System’ with ‘Any Type of data payload’ and ‘Any Time Stamp’, because, the SBK is not specific to particular type of storage system, it can be used for performance benchmarking of any storage system, let it be file system, databases , any distributed storage systems or message queues by adding SBK driver which specifies the IO operations of storage system. you can find the list of supported drivers below. The SBK supports variety of payloads too, such as byte array, byte buffer, string, and you can add your own payload type. The Latency values can be measured either in milliseconds, microseconds or nanoseconds using SBK.

SBK supports performance benchmarking of following storage systems

  1. Local mounted File Systems
  2. Java Concurrent Queue [Message Queue]
  3. Apache Kafka
  4. Apache Pulsar
  5. Pravega
  6. HDFS
  7. Apache Bookkeeper
  8. RabbitMQ
  9. RocketMQ
  10. ActiveMQ Artemis
  11. NATS Distributed Messaging
  12. NATS Streaming Storage
  13. NSQ
  14. JDBC
  15. Apache Derby
  16. MySQL
  17. PostgreSQL
  18. Microsoft SQL
  19. SQLite
  20. MinIO
  21. FoundationDB
  22. FoundationDB Record Layer
  23. FoundationDB Document Layer
  24. MongoDB
  25. CockroachDB
  26. RocksDB
  27. Apache Ignite
  28. Apache CouchDB
  29. Apache Hive
  30. MariaDB
  31. Redpanda
  32. Redis

In the future, many more storage systems drivers will be plugged in

we welcome open source developers to contribute to this project by adding a driver your storage device and any features to SBK. Refer to :

Build SBK

Prerequisites

Building

Checkout the source code:

git clone https://github.com/kmgowda/SBK.git
cd SBK

Build the SBK:

./gradlew build

untar the SBK to local folder

tar -xvf ./build/distributions/sbk.tar -C ./build/distributions/.

Running SBK locally:

<SBK directory>/./build/distributions/sbk/bin/sbk -help
...
usage: sbk
 -class <arg>        Storage Driver Class,
                     Available Drivers [Artemis, AsyncFile, BookKeeper,
                     CSV, ConcurrentQ, CouchDB, Derby, FdbRecord, File,
                     FileStream, FoundationDB, HDFS, Hive, Ignite, Jdbc,
                     Kafka, MariaDB, MinIO, MongoDB, MsSql, MySQL, Nats,
                     NatsStream, Nsq, Null, PostgreSQL, Pravega, Pulsar,
                     RabbitMQ, RedPanda, RocketMQ, RocksDB, SQLite]
 -context <arg>      Prometheus Metric context; default context:
                     9718/metrics; 'no' disables the metrics
 -help               Help message
 -readers <arg>      Number of readers
 -records <arg>      Number of records(events) if 'seconds' not specified;
                     otherwise, Maximum records per second by writer(s)
                     and/or Number of records per reader
 -seconds <arg>      Number of seconds to run; if not specified, runs
                     forever
 -size <arg>         Size of each message (event or record)
 -sync <arg>         Each Writer calls flush/sync after writing <arg>
                     number of of events(records) ; <arg> number of
                     events(records) per Write or Read Transaction
 -throughput <arg>   if > 0 , throughput in MB/s
                     if 0 , writes/reads 'records'
                     if -1, get the maximum throughput (default: -1)
 -time <arg>         Latency Time Unit [ms:MILLISECONDS, mcs:MICROSECONDS,
                     ns:NANOSECONDS]; default: ms
 -writers <arg>      Number of writers


Just to check the SBK build issue the command

./gradlew check

Build only the SBK install binary

./gradlew installDist

executable binary will be available at : [SBK directory]/./build/install/sbk/bin/sbk

Running Performance benchmarking

The SBK can be executed to

SBK outputs the data written/read , average throughput and latency , maximum latency and the latency percentiles 10th, 25th, 50th, 75th, 95th, 99th , 99.9th and 99.99th for every 5 seconds time interval as show below.

Pulsar Writing    1500124 records,  299964.8 records/sec,    28.61 MB/sec,      3.2 ms avg latency,      42 ms max latency;        0 invalid latencies; Discarded Latencies:       0 lower,        0 higher;      2 ms 10th,       3 ms 25th,       3 ms 50th,       3 ms 75th,       5 ms 90th,       5 ms 95th,       6 ms 99th,       9 ms 99.9th,      21 ms 99.99th.
Pulsar Writing    1539995 records,  307937.4 records/sec,    29.37 MB/sec,      3.2 ms avg latency,      14 ms max latency;        0 invalid latencies; Discarded Latencies:       0 lower,        0 higher;      2 ms 10th,       3 ms 25th,       3 ms 50th,       3 ms 75th,       4 ms 90th,       5 ms 95th,       6 ms 99th,       9 ms 99.9th,      11 ms 99.99th.
Pulsar Writing    1534073 records,  306691.9 records/sec,    29.25 MB/sec,      3.2 ms avg latency,      76 ms max latency;        0 invalid latencies; Discarded Latencies:       0 lower,        0 higher;      2 ms 10th,       3 ms 25th,       3 ms 50th,       3 ms 75th,       4 ms 90th,       5 ms 95th,       6 ms 99th,      36 ms 99.9th,      74 ms 99.99th.
Pulsar Writing    1546930 records,  309200.5 records/sec,    29.49 MB/sec,      3.2 ms avg latency,      24 ms max latency;        0 invalid latencies; Discarded Latencies:       0 lower,        0 higher;      2 ms 10th,       3 ms 25th,       3 ms 50th,       3 ms 75th,       4 ms 90th,       5 ms 95th,       6 ms 99th,       9 ms 99.9th,      23 ms 99.99th.
Pulsar Writing    1619653 records,  323801.1 records/sec,    30.88 MB/sec,      3.0 ms avg latency,      12 ms max latency;        0 invalid latencies; Discarded Latencies:       0 lower,        0 higher;      2 ms 10th,       3 ms 25th,       3 ms 50th,       3 ms 75th,       4 ms 90th,       5 ms 95th,       5 ms 99th,       8 ms 99.9th,      10 ms 99.99th.
Pulsar Writing    1573613 records,  314596.8 records/sec,    30.00 MB/sec,      3.1 ms avg latency,      23 ms max latency;        0 invalid latencies; Discarded Latencies:       0 lower,        0 higher;      2 ms 10th,       3 ms 25th,       3 ms 50th,       3 ms 75th,       4 ms 90th,       5 ms 95th,       5 ms 99th,      10 ms 99.9th,      21 ms 99.99th.
Pulsar Writing    1565730 records,  312958.2 records/sec,    29.85 MB/sec,      3.1 ms avg latency,      25 ms max latency;        0 invalid latencies; Discarded Latencies:       0 lower,        0 higher;      2 ms 10th,       3 ms 25th,       3 ms 50th,       3 ms 75th,       4 ms 90th,       5 ms 95th,       6 ms 99th,      20 ms 99.9th,      23 ms 99.99th.
Pulsar Writing    1580433 records,  316023.4 records/sec,    30.14 MB/sec,      3.1 ms avg latency,      25 ms max latency;        0 invalid latencies; Discarded Latencies:       0 lower,        0 higher;      2 ms 10th,       3 ms 25th,       3 ms 50th,       3 ms 75th,       4 ms 90th,       5 ms 95th,       5 ms 99th,      22 ms 99.9th,      22 ms 99.99th.

At the end of the benchmarking session, SBK outputs the total data written/read , average throughput and latency , maximum latency and the latency percentiles 10th, 25th, 50th, 75th, 95th, 99th , 99.9th and 99.99th for the complete data records written/read. An example final output is show as below:

Total : Pulsar Writing   92396507 records,  307987.3 records/sec,    29.37 MB/sec,      3.2 ms avg latency,     142 ms max latency;        0 invalid latencies; Discarded Latencies:       0 lower,        0 higher;      2 ms 10th,       3 ms 25th,       3 ms 50th,       3 ms 75th,       4 ms 90th,       5 ms 95th,       6 ms 99th,      21 ms 99.9th,      49 ms 99.99th.

Grafana Dashboards of SBK

When you run the SBK, by default it starts the http server and all the output benchmark data are directed to the default port number: 9718 and metrics context. if you want to change the port number and context, you can use the command line argument -context to change the same. you have to run the prometheus monitoring system (server [default port number is 9090] cum client) which pulls/fetches the benchmark data from the local/remote http server. If you want to include additional SBK nodes/instances to fetch the performance data or from port number other than 9718, you need to extend or update targets.json
In case, if you are fetching metrics/benchmark data from remote http server , or from the context other than metrics then you need to change the default prometheus server configuration too. Run the grafana server (cum a client) to fetch the benchmark data from prometheus. For example, if you are running local grafana server then by default it fetches the data from prometheus server at the local port 9090. You can access the local grafana server at localhost:3000 in your browser using admin/admin as default username / password. you can import the grafana dashboards to fetch the SBK benchmark data of the existing supported storage drivers from grafana dashboards.

The sample output of Standalone Pulsar benchmark data with grafana is below

Pulsar Grafana Dashboard

Port conflicts between storage servers and grafana/prometheus

SBK Docker Containers

The SBK Docker images are available at SBK Docker

The SBK docker image pull command is

docker pull kmgowda/sbk

you can straightaway run the docker image too, For example

docker run  -p 127.0.0.1:9718:9718/tcp  kmgowda/sbk:latest -class  rabbitmq  -broker 192.168.0.192 -topic kmg-topic-11  -writers 5  -readers 1 -size 100 -seconds 60

SBK Docker Compose

The SBK docker compose consists of SBK docker image, Grafana and prometheus docker images. The grafana image contains the dashboards which can be directly deployed for the performance analytics.

As an example, just follow the below steps to see the performance graphs

  1. In the SBK directory run the ‘SBK’ service of the docker compose file as follows.

    <SBK dir>% ./docker-compose run sbk  -class concurrentq -writers 1  -readers 5 -size 1000 -seconds 120 
    
    
  2. login to grafana local host port 3000 with username admin and password sbk
  3. go to dashboard menu and pick the dashboard of the storage device on which you are running the performance benchmarking. in the above example, you can choose the Concurrent Queue dashboard.
  4. The SBK docker compose runs the SBK image as docker container. In case, if you are running SBK as an application, and you want to see the SBK performance graphs using Grafana, then use Grafana Docker compose

SBK Kubernetes

check these SBK Kubernetes Deployments samples for details on SBK as kubernetes pod. If you want to run the Grafana and prometheus as Kubernetes pods, then use [Grafana Kubernetes deployment] (https://github.com/kmgowda/SBK/tree/master/grafana#grafana-with-kubernetes)

SBK Execution Modes

The SBK can be executed in the following modes:

1. Burst Mode (Max rate mode)
2. Throughput Mode
3. Rate limiter Mode
4. End to End Latency Mode

1 - Burst Mode / Max Rate Mode

In this mode, the SBK pushes/pulls the messages to/from the storage client(device/driver) as much as possible. This mode is used to find the maximum and throughput that can be obtained from the storage device or storage cluster (server). This mode can be used for both writers and readers. By default, the SBK runs in Burst mode.

For example: The Burst mode for pulsar single writer as follows

<SBK directory>./build/distributions/sbk/bin/sbk -class Pulsar -admin http://localhost:8080 -broker tcp://localhost:6650 -topic topic-k-223  -partitions 1  -writers 1 -size 1000  -seconds 60 -throughput -1


The -throughput -1  indicates the burst mode. Note that, you dont supply the parameter -throughput then also its burst mode.
This test will executed for 60 seconds because option -seconds 60 is used.
This test tries to write and read events of size 1000 bytes to/from the topic 'topic-k-223'.
The option '-broker tcp://localhost:6650' specifies the Pulsar broker IP address and port number for write operations.
The option '-admin http://localhost:8080' specifies the Pulsar admin IP and port number for topic creation and deletion.
Note that -producers 1 indicates 1 producer/writers.

in the case you want to write/read the certain number of records.events use the -records option without -seconds option as follows

<SBK directory>/build/distributions/sbk/bin/sbk -class Pulsar -admin http://localhost:8080 -broker tcp://localhost:6650 -topic topic-k-223  -partitions 1  -writers 1 -size 1000  -records 100000 -throughput -1

-records <number> indicates that total <number> of records to write/read

2 - Throughput Mode

In this mode, the SBK pushes/pull/from the messages to the storage client(device/driver) with specified approximate maximum throughput in terms of Mega Bytes/second (MB/s). This mode is used to find the least latency that can be obtained from the storage device or storage cluster (server) for given throughput.

For example:  The througput mode for pulsar 5 writers as follows
<SBK directory> ./build/distributions/sbk/bin/sbk -class Pulsar -admin http://localhost:8080 -broker tcp://localhost:6650 -topic topic-k-223  -partitions 1  -writers 5 -size 1000  -seconds 120  -throughput 10

The -throughput <positive number>  indicates the Throughput mode.

This test will be executed with approximate max throughput of 10MB/sec.
This test will executed for 120 seconds (2 minutes) because option -seconds 120 is used.
This test tries to write and read events of size 1000 bytes to/from the topic 'topic-k-223' of 1 partition.
If the toic 'topic-k-223' is not existing , then it will be created with  1 segment.
if the steam is already existing then it will be deleted and recreated with 1 segment.
Note that -writers 5 indicates 5 producers/writers .

in the case you want to write/read the certain number of events use the -records option without -seconds option as follows

<SBK directory>./build/distributions/sbk/bin/sbk -class Pulsar -admin http://localhost:8080 -broker tcp://localhost:6650 -topic topic-k-223  -partitions 1  -writers 5 -size 1000  -records 1000000  -throughput 10

-records 1000000 indicates that total 1000000 (1 million) of events will be written at the throughput speed of 10MB/sec

3 - Rate limiter Mode

This mode is another form of controlling writers/readers throughput by limiting the number of records per second. In this mode, the SBK pushes/pull the messages to/from the storage client (device/driver) with specified approximate maximum records per sec. This mode is used to find the least latency that can be obtained from the storage device or storage cluster (server) for events rate.

For example:  The Rate limiter Mode for pulsar 5 writers as follows

<SBK directory>./build/distributions/sbk/bin/sbk -class Pulsar -admin http://localhost:8080 -broke
r tcp://localhost:6650 -topic topic-k-225  -partitions 10  -writers 5 -size 100  -seconds 60  -records 1000

The -records <records numbes>  (1000) specifies the records per second to write.
Note that the option "-throughput"  SHOULD NOT supplied for this  Rate limiter Mode.

This test will be executed with approximate 1000 events per second by 5 writers.
The topic "topic-k-225" with 10 partitions are created to run this test.
This test will executed for 60seconds (1 minutes) because option -seconds 60 is used.
Note that in this mode, there is 'NO total number of events' to specify hence user must supply the time to run using -seconds option.

4 - End to End Latency Mode

In this mode, the SBK writes and read the messages to the storage client (device/driver) and records the end to end latency. End to end latency means the time duration between the beginning of the writing event/record to stream, and the time after reading the event/record. in this mode user must specify both the number of writers and readers. The -throughput option (Throughput mode) or -records (late limiter) can used to limit the writers throughput or records rate.

For example: The End to End latency of between single writer and single reader of pulsar is as follows:

<SBK directory>./build/distributions/sbk/bin/sbk -class Pulsar -admin http://localhost:8080 -broker tcp://localhost:6650 -topic topic-km-1  -partitions 1  -writers 1 -readers 1 -size 1000 -throughput -1 -seconds 60 

The user should specify both writers and readers count for write to read or End to End latency mode.
The -throughput -1 specifies the writes tries to write the events at the maximum possible speed.

Contributing to SBK

All submissions to the master are done through pull requests. If you’d like to make a change:

  1. Create a new Git hub issue (SBK issues) describing the problem / feature.
  2. Fork a branch.
  3. Make your changes.
    • you can refer (Oracle Java Coding Style) for coding style; however, Running the Gradle build helps you to fix the Coding syte issues too.
  4. Verify all changes are working and Gradle build checkstyle is good.
  5. Submit a pull request with Issue number, Description and your Sign-off.

Make sure that you update the issue with all details of testing you have done; it will be helpful for me to review and merge.

Another important point to consider is how to keep up with changes against the base the branch (the one your pull request is comparing against). Let’s assume that the base branch is master. To make sure that your changes reflect the recent commits, I recommend that you rebase frequently. The command I suggest you use is:

git pull --rebase upstream master
git push --force origin <pr-branch-name>

in the above, I’m assuming that:

The rebase might introduce conflicts, so you better do it frequently to avoid outrageous sessions of conflict resolving.

Lombok

SBK uses [Lombok] for code optimizations; I suggest the same for all the contributors too. If you use an IDE you’ll need to install a plugin to make the IDE understand it. Using IntelliJ is recommended.

To import the source into IntelliJ:

  1. Import the project directory into IntelliJ IDE. It will automatically detect the gradle project and import things correctly.
  2. Enable Annotation Processing by going to Build, Execution, Deployment -> Compiler > Annotation Processors and checking ‘Enable annotation processing’.
  3. Install the Lombok Plugin. This can be found in Preferences -> Plugins. Restart your IDE.
  4. SBK should now compile properly.

For eclipse, you can generate eclipse project files by running ./gradlew eclipse.

Add your driver to SBK

  1. Create the gradle subproject preferable with the name driver-<your driver(storage device) name>.

  2. Create the package io.sbk.< your driver name>

  3. In your driver package you have to implement the Interface: [Storage]

    • See the Example: [Pulsar class]

    • you have to implement the following methods of Benchmark Interface:

      a). Add the Additional parameters (Command line Parameters) for your driver :[addArgs]

      • The default command line parameters are listed in the help output here : [Building SBK]

      b). Parse your driver specific parameters: [parseArgs]

      c). Open the storage: [openStorage]

      d). Close the storage:[closeStorage]

      e). Create a single writer instance:[createWriter]

      • Create Writer will be called multiple times by SBK in case of Multi writers are specified in the command line.

      f). Create a single Reader instance:[createReader]

      • Create Reader will be called multiple times by SBK in case of Multi readers are specified in the command line.

      g). Get the Data Type :[getDataType]

      • In case if your data type is byte[] (Byte Array), No need to override this method. see the example: [Pulsar class]
      • If your Benchmark, Reader and Writer classes operates on different data type such as String or custom data type, then you have to override this default implementation.
  4. Implement the Writer Interface: [Writer]

    • See the Example: [Pulsar Writer]

    • you have to implement the following methods of Writer class:

      a). Writer Data [Async or Sync]: [writeAsync]

      b). Flush the data: [sync]

      c). Close the Writer: [close]

      d). In case , if you want to have your own recordWrite implementation to write data and record the start and end time, then you can override: [recordWrite]

  5. Implement the Reader Interface: [Reader]

  6. Add the Gradle dependency [ compile project(“:sbk-api”)] to your sub-project (driver)

  7. Add your subproject to main gradle as dependency.

  8. That’s all ; Now, Build the SBK included your driver with the command:

./gradlew build

untar the SBK to local folder

tar -xvf ./build/distributions/sbk.tar -C ./build/distributions/.
  1. To invoke the benchmarking of the driver you have issue the parameters “-class < your driver name>”

Example: For pulsar driver

<SBK directory>./build/distributions/sbk/bin/sbk  -class pulsar -help

usage: sbk -class pulsar
 -ackQuorum <arg>       AckQuorum default: 1
 -admin <arg>           Admin URI, required to create the partitioned
                        topic, default: null
 -broker <arg>          Broker URI, default: tcp://localhost:6650
 -cluster <arg>         Cluster name (optional parameter)
 -context <arg>         Prometheus Metric context; default context:
                        9718/metrics; 'no' disables the metrics
 -deduplication <arg>   Enable or Disable Deduplication; default: false
 -ensembleSize <arg>    EnsembleSize default: 1
 -help                  Help message
 -partitions <arg>      Number of partitions of the topic, default: 1
 -readers <arg>         Number of readers
 -records <arg>         Number of records(events) if 'seconds' not
                        specified;
                        otherwise, Maximum records per second by writer(s)
                        and/or Number of records per reader
 -seconds <arg>         Number of seconds to run; if not specified, runs
                        forever
 -size <arg>            Size of each message (event or record)
 -sync <arg>            Each Writer calls flush/sync after writing <arg>
                        number of of events(records) ; <arg> number of
                        events(records) per Write or Read Transaction
 -threads <arg>         io threads per Topic, default: 1
 -throughput <arg>      if > 0 , throughput in MB/s
                        if 0 , writes/reads 'records'
                        if -1, get the maximum throughput (default: -1)
 -time <arg>            Latency Time Unit [ms:MILLISECONDS,
                        mcs:MICROSECONDS, ns:NANOSECONDS]; default: ms
 -topic <arg>           Topic name, default : test
 -writeQuorum <arg>     WriteQuorum default: 1
 -writers <arg>         Number of writers

Use SBK git hub packages

Instead of using entire SBK framework, if you just want to use the SBK framework API packages to measure the performance benchmarking of your storage device/software, then follow the below simple and easy steps.

  1. Add the SBK git hub package repository and dependency in gradle build file of your project as follows

     repositories {
         mavenCentral()
    
         maven {
             name = "GitHubPackages"
             url = uri("https://maven.pkg.github.com/kmgowda/SBK")
    
             credentials {
                 username = project.findProperty("github.user") ?: System.getenv("GITHUB_USERNAME")
                 password = project.findProperty("github.token") ?: System.getenv("GITHUB_TOKEN")
             }
        }
     }
    
     dependencies {
         implementation 'sbk:sbk-api:0.86'
     }
    
    

    few points to remember here

    • you need to authenticate with your git hub username (GITHUB_USERNAME) and git hub token (GITHUB_TOKEN)
    • mavenCentral() repository is required to fetch the SBK’s dependencies too.
    • check this example: File system benchmarking git hub build
  2. Extend the storage interface Storage by following steps 1 to 5 described in Add your storage driver

  3. Create a Main method to supply your storage class object to SBK to run/conduct the performance benchmarking

     public static void main(final String[] args) {
         Storage device = new <your storage class, extending the Storage interface>;
         try {
            
             //Start the File system benchmarking here
                
             Sbk.run(args  /* Command line Arguments */ , 
                   device /* your storage deivce object */ , 
                   null /* Name of the your performance benchmarking application, by default , storage class name will be used */ ,
                   null /* Logger, if you dont have your own logger, then prometheus logger will be used by default */ );
                
                
         } catch (ParseException | IllegalArgumentException | IOException |
                 InterruptedException | ExecutionException | TimeoutException ex) {
             ex.printStackTrace();
             System.exit(1);
         }
         System.exit(0);
     }
    
    
  4. That’s all! Run your main method (your java application ) with “-help” to see the benchmarking options.

Use SBK from JitPack

The SBK API package is available in JitPack Repository too. To use the SBK-API package from Jitpack, follow the below simple and easy steps

  1. Add the SBK git hub package repository and dependency in gradle build file of your project as follows

     repositories {
         mavenCentral()
         maven {
             url 'https://jitpack.io'
         }
     }
    
     dependencies {
         implementation 'com.github.kmgowda.SBK:sbk-api:0.86'
     }
       
    

    few points to remember here

  2. Extend the storage interface Storage by following steps 1 to 5 described in Add your storage driver
  3. Create a Main method to supply your storage class object to SBK to run/conduct the performance benchmarking

     public static void main(final String[] args) {
         Storage device = new <your storage class, extending the Storage interface>;
         try {
            
             //Start the File system benchmarking here
                
             Sbk.run(args  /* Command line Arguments */ , 
                   device /* your storage deivce object */ , 
                   null /* Name of the your performance benchmarking application, by default , storage class name will be used */ ,
                   null /* Logger, if you dont have your own logger, then prometheus logger will be used by default */ );
                
                
         } catch (ParseException | IllegalArgumentException | IOException |
                 InterruptedException | ExecutionException | TimeoutException ex) {
             ex.printStackTrace();
             System.exit(1);
         }
         System.exit(0);
     }
    
    
  4. That’s all! Run your main method (your java application ) with “-help” to see the benchmarking options.

Use SBK from Maven Central

The SBK APIs Package is available at maven central too. to use the sbk-api package, follow below steps

  1. Add the SBK git hub package repository and dependency in gradle build file of your project as follows

     repositories {
         mavenCentral()
     }
    
     dependencies {
         implementation 'io.github.kmgowda:sbk-api:0.86'
     }
    

    few points to remember here

  2. Extend the storage interface Storage by following steps 1 to 5 described in Add your storage driver
  3. Create a Main method to supply your storage class object to SBK to run/conduct the performance benchmarking

     public static void main(final String[] args) {
         Storage device = new <your storage class, extending the Storage interface>;
         try {
            
             //Start the File system benchmarking here
                
             Sbk.run(args  /* Command line Arguments */ , 
                   device /* your storage deivce object */ , 
                   null /* Name of the your performance benchmarking application, by default , storage class name will be used */ ,
                   null /* Logger, if you dont have your own logger, then prometheus logger will be used by default */ );
                
                
         } catch (ParseException | IllegalArgumentException | IOException |
                 InterruptedException | ExecutionException | TimeoutException ex) {
             ex.printStackTrace();
             System.exit(1);
         }
         System.exit(0);
     }
          
    
  4. That’s all! Run your main method (your java application ) with “-help” to see the benchmarking options.