-
Notifications
You must be signed in to change notification settings - Fork 105
Configuration
NDBench leverages Guice to reduce repetition and in favor of a more readable configuration. The registration of the listener takes place in the web.xml. InjectedWebListener is the logical place where the injectors are created and configured.
bind(NdBenchMonitor.class).to(FakeMonitor.class);
bind(IClusterDiscovery.class).to(LocalClusterDiscovery.class);
bind(DataGenerator.class).to(StringDataGenerator.class);To use NDBench on AWS, you need to replace LocalClusterDiscovery with AWSLocalClusterDiscovery.
NdBench configuration is backed by Netflix OSS - Archaius2 implementation.
The most straight-forward way to modify NdBench properties when you are running via Tomcat is by adding system property settings to the CATALINA_OPTS environment variable in the /bin directory of your Tomcat installation. For example, if you wished to change the number of writers in your benchmark to 10, you would stick the folllowing line at the very end of the file <TOMCAT_DIR>/bin/setenv.sh:
export CATALINA_OPTS=" -Dndbench.config.numWriters=10 ... {other settings} ..."
The approach for jetty and other containers would be similar.
Default Configuration prefix - ndbench.config.. For example ndbench.config.numKeys.
Note: Every config has to be prefixed with configuration prefix mentioned above.
Archaius2 provides a variety of property sources which can be used to configure NDBench. Configuration value changes during runtime require a restart to take effect. See the /config/tunable REST API for configurations that can be set at runtime without a restart.
| Config Name | Property path | Default value | Description |
|---|---|---|---|
| numKeys | ndbench.config.numKeys | 1000 | Number of Keys to be generated and stored in memory of NdBench instance.. The number of keys you allocate may impact how your benchmark runs for plug-in clients that perform UPSERT style writes (that is: writes which create an object if the corresponding key is not present, and which update the object it if its key exists). This occurs with the Elasticsearch REST client, for example: if the number of writes you perform starts to exceed the number of keys alloted then you will see the document count in your test index cease to increase.) |
| numValues | ndbench.config.numValues | 200 | Value cache size. The higher the number, the more JVM memory used and more likely to get a unique value from DataGenerator.getRandomValue()
|
| dataSize | ndbench.config.dataSize | 128 | Size in bytes of value String's |
| useVariableDataSize | ndbench.config.useVariableDataSize | false | If true, will randomly pick (ie. uniform distribution) the value size in bytes in [dataSizeLowerBound, dataSizeUpperBound)
|
| dataSizeLowerBound | ndbench.config.dataSizeLowerBound | 1000 | Lower bound of data size in bytes in case of variable data size is generated |
| dataSizeUpperBound | ndbench.config.dataSizeUpperBound | 5000 | Upper bound of data size in bytes in case of variable data size is generated |
| preLoadKeys | ndbench.config.preLoadKeys | false | Indicates whether keys to be generated and stored in it's in-memory(JVM) for the duration NdBench's runtime life cycle |
| zipfExponent | ndbench.config.zipfExponent | 0.5 | If using the ZIPFIAN Key generator this controls how skewed the Zipf Distribution is. Note that this should be between 0 (very little skew) and 0.99 (very much skew). |
| generateCheckSum | ndbench.config.generateCheckSum | false | If set to true, DefaultDataGenerator generates values which have checksum of the value embedded. |
| validateCheckSum | ndbench.config.validateCheckSum | false | If set to true, readers may parse the read value and validate if the embedded checksum is still valid for the read value. This will adversely impact the read performance as it involves parsing the value, generating and comparing checksums. |
| Config Name | Property path | Default value | Description |
|---|---|---|---|
| numWriters | ndbench.config.numWriters | Runtime.availableProcessors() * 4 |
Number of writer threads to used |
| numReaders | ndbench.config.numReaders | Runtime.availableProcessors() * 4 |
Number of reader threads to be used |
| backfillKeySlots | ndbench.config.backfillKeySlots | 1 | Number of backfill threads to be used |
| writeRateLimit | ndbench.config.writeRateLimit | 100 | Number of writes per sec per NdBench instance |
| readRateLimit | ndbench.config.readRateLimit | 100 | Number of reads per sec per NdBench instance |
| Config Name | Property path | Default value | Description |
|---|---|---|---|
| writeEnabled | ndbench.config.writeEnabled | true | Enable writes |
| readEnabled | ndbench.config.readEnabled | true | Enable reads |
| Config Name | Default value | Description |
|---|---|---|
| statsUpdateFreqSeconds | 5 | Debug log stats update frequency in seconds |
| statsResetFreqSeconds | 200 | Debug log stats reset frequency in seconds |
| Config Name | Default value | Description |
|---|---|---|
| autoTuneEnabled | false | whether or not the benchmark driver will attempt to use auto-tuning to find optimal read and write rate limits |
| autoTuneRampPeriodMillisecs | 60 | the period within which the driver will attempt to raise a rate limit from its initial to its final value -- must be an integral multiple of autoTuneIncrementIntervalMillisecs. |
| autoTuneIncrementIntervalMillisecs | 1 | the number of steps within which the driver will attempt to adjust a rate limit from its initial to its final value, as given by the formula: autoTuneRampPeriodMillisecs / autoTuneIncrementIntervalMillisecs |
| autoTuneFinalWriteRate | 1000 | the upper bound on the write rate limit that the driver will attempt to adjust to if autoTuneEnabled is set to true |
| autoTuneWriteFailureRatioThreshold | 0.01F | Threshold write failure ratio beyond which no auto-tune increase will occur. If failure rate grows larger than this threshold then auto-tune triggered rate increases will cease. |
Properties inherently use Archaius configuration.
But you can use any of the Archaius2 property source methods to supply properties whichever way you would like. (eg. application.properties or System properties)
Another way to provide your properties is by implementing IConfiguration interface.