forked from k8-scalar/k8-scalar
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathexperiment.properties
125 lines (105 loc) · 5.34 KB
/
experiment.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
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
## LOAD PROFILE
#
# The load profile varies between the min and max numbers of concurrent users. It
# starts low, then ramps up to a peak which is sustained for a specific time, and
# then gradually ramps down again to the minimum load. Both ramping up and down is
# done linearly. Therefore, the effective load, in function of time, looks something
# like this:
# ____
# / \
# ____ / \
# / \ / \
# / \ / \
# ____/ \_______/ \______ ...
#
# The number of concurrent users for peak load for the entire cluster. For each
# number in this comma separated list, a new run is started.
user_peak_load=1,200,400,600
# The fraction of concurrent users used for warm up (i.e., in the interval [0,1]).
# For a peak load of 100 and a warmup fraction of 0.1, 10 users would be started
# during warmup.
user_warmup_fraction=1
# The initial period of minimum load, in secconds.
user_warmup_duration=1
# The duration of the ramping up period, in seconds.
user_ramp_up_duration=0
# The duration of the peak load, in seconds.
user_peak_duration=10
# The duration of the ramping down period, in seconds.
user_ramp_down_duration=0
# The final cool down period of minimum load, in seconds.
user_cooldown_duration=0
# How long to wait between multiple consecutive runs, in seconds.
user_wait_inbetween_runs=0
# Scalar cluster size. The master load generator will wait until this many nodes
# (including the master) report ready.
scalar_minimal_cluster_size=1
# Wait for user input (i.e., for the user to press ENTER) before starting?
scalar_wait_for_user_input=false
# The fraction of all results to keep for final statistics calculation. In the
# case of high load - long duration experiments, the generated data might be too
# large to keep in memory and send to the master. This value indicates how much
# data to retain (e.g., 0.1 indicates 10% of all request data is kept). The
# retained request data is selected at random.
residence_times_sample_fraction=1
## GENERAL USER CONFIGURATION
#
# The think time strategy factory to use. This class will be used to create think time strategies,
# which are used by user objects to calculate the "think time", i.e., time to wait between two
# iterations of their main loop. Built-in options are constant think time,
# exponential think time, uniform think time, and histogram think time.
think_time_strategy_factory=ConstantThinkTimeStrategyFactory
# In the case of the HistogramThinkTimeStrategyFactory, think times are chosen
# to belong to a histogram specified in a CSV file with the following format:
## Bin start, bin end, count
# 0; 500; 0
# 500; 1000; 10
# 1000; 1500; 60
# The above file would indicate that 10/70 of all traffic has a residence time
# uniformly distributed in the interval [500, 1000]ms, and 60/70 of all traffic
# has a residence time uniformly chosen from [1000,1500]ms.
#think_time=dist/think_times.csv
# In the case of other think time strategies, this value denotes the mean think
# time in milliseconds.
think_time=1000
## USER CONFIGURATION
#
# List the user class files to use in user_implementations in the following
# format:
# SomeTestUser:0.3,OtherTestUser:0.7
# This will ensure that 30% of user objects are SomeTestUser instances, while
# 70% will be OtherTestUser instances.
#
# Built-in users are:
# - TestUser: Generates an empty request.
# - RemoteTestUser: Generates a HTTP request to the target.
# - DistributedTestUser: Writes and reads a value from the data backend.
user_implementations=be.kuleuven.distrinet.scalar.users.TestUser:0,\
be.kuleuven.distrinet.scalar.users.RemoteTestUser:0.3:,\
be.kuleuven.distrinet.scalar.users.DistributedTestUser:0.7
# Similar to user_implementations, the prestart list specifies how many
# instances of each user type should be prestarted and run for every run of the
# experiment, not including the normal user load. For instance, if you want a
# population of 1,100,1000,... NaiveShopUsers and 1 Attacker throughout the
# experiment, then
user_implementations_prestart=be.kuleuven.distrinet.scalar.users.TestUser:0,\
be.kuleuven.distrinet.scalar.users.DistributedTestUser:0
# For remote test users, which HTTP method to use (e.g., GET, HEAD, ...).
remote_test_user_method=HEAD
# Users have built-in support for storing account details (username/password), and generating their
# own incremental username/password combinations by appending a number to a
# prefix string. In both login_account and login_password, #ID# is replaced by a
# randomly chosen value from [0,max_user_id]. If the number of users is lower or
# equal to max_user_id, the generated login account and password strings are
# guaranteed to be unique across the cluster. If the number of users is higher,
# the extra users are assigned randomly chosen ID values.
login_account=mytester#ID#
login_password=mytester#ID#
max_user_id=1000
# URLs of the host systems to be benchmarked. Separate multiple URLs with a , . These are accessible in user
# objects by calling 'targetUrl()'.
target_urls=http://pong.cs.kuleuven.be/
# Whether to emulate "sticky load balancing". If true, every time a user calls
# targetUrl(), the same target URL is returned. If false, a random target URL is
# returned.
sticky_balancing=false