Documentation > Deployment > Benchmark Client Configuration

This page provides documentation on the various ways to tune, control, and configure the execution behavior of clients in H-Store’s benchmark framework.

Best Performance Checklist

The following is a list of things that you need to do when running experiments for research projects in order to get maximum performance:

• Disable JVM Asserts
  All you need to do is set site.jvm_asserts to false. H-Store will take care of the rest!
• Use Blocking Clients
  Unless you are doing experiments to measure the absolute maximum sustained throughput of the system, you will want to use blocking clients (client.blocking=true). This will ensure that the transactions complete with a realistic latency (i.e., >50ms). With blocking clients, you can set the transaction request rate of the client threads to a high value (e.g., 100000).
• Scale the Number of Client Threads with the Number of Partitions
  As the size of your cluster increases, you will also need to scale up the number of client threads to ensure that the database is saturated. This is necessary when using blocking clients. Depending on the benchmark, as the number of partitions doubles you will need to double the number of client threads (client.threads_per_host).

Transaction Workload Mix

Each of H-Store’s built-in benchmarks comes with a default workload distribution. This defines how likely each particular stored procedure type will be selected by a client thread for its next request. There are occasions, however, where you may need to alter this workload mix for whatever reason. You can control this mix using the client.weights configuration option. The expected value for this option is a comma separated list of pairs in the format of <ProcedureName:Weight>. The ProcedureName is the case-sensitive name of the target’s stored procedure class name. You can use * as a wild card that matches all procedures not explicitly listed in this parameter. The Weight is an integer value between 0 and 100 (inclusive) that corresponds to what percentage of the executed workload should be made up of that particular procedure. All of the weights given with this parameter must add up to 100.

For example, let’s say for the TM1 benchmark that we want to execute the GetAccessData and UpdateLocation procedures 60% and 40% of the time, respectively, and disable all of the remaining procedures. The corresponding command would be:

ant hstore-benchmark -Dproject=tm1 \
   -Dclient.weights="GetAccessData:60,UpdateLocation:40,*:0"

Note that you do not need to recompile the benchmark catalog with hstore-prepare if you change the workload mix. Not all benchmarks support this option yet.

Controlling Output

There are several parameters that you can use to control what information the client prints out to its log file, as well as how often it is printed. You can also control what information is collected during a benchmark and is printed at the end of the run.

The BenchmarkController separates the output generated from client thread and writes it to a separate file in the directory defined by client.log_dir. You can control whether a new is created each benchmark run or whether it will overwrite existing files with the client.log_backup. If this configuration parameter is set to true, then the BenchmarkController will rename any existing files in clients’ log directory to a different file with the timestamp added to its name.