-
Notifications
You must be signed in to change notification settings - Fork 4
/
benchfoundry_consbench_local.properties
78 lines (61 loc) · 4.24 KB
/
benchfoundry_consbench_local.properties
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
# example of a BenchFoundry config file, needs to be placed on the BenchFoundry master machine only
# leading and tailing whitespaces as well as empty lines will be ignored
# comments lines should start with the # character
##################################################################################################
# Please, note: Incompatible combinations (e.g., for the two classes or oplist + trace) may result
# in a hard crash of BenchFoundry or unexpected behavior!
##################################################################################################
# location of the schema input file which should be a sequence of DDL statements
schemaFilename:consbench_schema.txt
# location of the file containing all the queries used in the respective trace
oplistFilename:consbench_ops.txt
# location of the file containing all parameters sets refered to in the trace files
paramFilename:consbench_params.txt
# location of the file containing all parameters sets refered to in the trace files
# this file will often be empty but may be used to forward special instructions to db
# connectors, e.g., for sending the request to a specific database replica.
custparamFilename:consbench_custparams.txt
# location of the trace file which will preload the database with an initial data set
# this trace may contain to entries
preloadTraceFilename:consbench_preload_trace.txt
# location of the trace file which will be used to warm up the SUT
# this file should typically not be empty but should for reasons of reproducibility only
# contain read requests as it will rarely be fully executed.
warmupTraceFilename:consbench_warmup_trace.txt
# location of the trace file of the actual experiment
experimentTraceFilename:consbench_exp_trace.txt
# location of the config file for the database connector
dbConnectorConfigFile:mariadb.properties
# directory where the output results shall be written to on all machines
resultDir:results
# factory class which will create a physical schema from the logical schema specified in the
# schema input file. For non-relational databases this may involve schema denormalization.
physicalSchemFactoryClass:de.tuberlin.ise.benchfoundry.physicalschema.factory.RelationalPhysicalSchemaFactory
# class which shall be used to connect to the SUT. Should correspond to the schema factory class above.
#dbConnectorClass:de.tuberlin.ise.BenchFoundry.connectors.impl.DummyRelationalConnector
dbConnectorClass:de.tuberlin.ise.benchfoundry.connectors.impl.MariadbRelationalConnector
# BenchFoundry will issue a prepare command to the database connector before sending the execute command
# at the poin in time specified in the trace. This property specifies the duration between prepare and
# execute command. Choosing high values will result in large thread pool sizes, choosing low values may
# cause delayed execution of transactions depending on the complexity of preparing transactions and the
# number of transactions per business process.
transactionPrepareTimeInMs:1000
# BenchFoundry will submit process instances to a thread pool for execution prior to the specified timestamp from
# the trace. This is done to assert on-time execution of the process. Choosing small values may lead to delay,
# high values may lead to significantly increased thread pool sizes.
processScheduleAheadTimeInMs:500
# The file that contains information on all slave instances. Use
# slaveFile:none
# if the master shall be run as single node BenchFoundry instance
slaveFile:none
# If this flag is set to true, then BenchFoundry will print a detailed error trace for each business process with an
# exception. If there are many exceptions, this may slow down the benchmark and cause scheduling delays.
doDetailledLoggingForExceptions:true
#If this flag is set to true, then BenchFoundry will use a closed workload scheduler for the experiment phase.
#Closed workload schedulers ignore all timing information from the trace and execute it as fast as possible
#based on a fixed-size threadpool.
closedWorkloadSchedulerInExperimentPhase:false
#If a closed workload scheduler is used for the experiment phase, this parameter determines the threadpool size.
#For the normal scheduler, this parameter is ignored.
#Will default to 8 if negative values or zero are used.
closedWorkloadSchedulerThreadpoolSize:8