weathervane.config

# Configuration file for the Weathervane benchmark
#
# It is possible to override the values of all
# of these parameters using command-line
# options to the Weathervane run-harness weathervane.pl.
# The name of the command-line parameter will be
# the same as the name in the configuration file, 
# prefixed by --. The only difference is that on 
# the command-line, boolean parameters are set to true
# simply by specifying them, e.g. --redeploy, 
# and set to false by prefixing the name of the 
# parameter with 'no', as in --noredeploy, which
# would be used if redeploy is set to true in the
# configuration file.
{

# Setting help to true will cause the run harness
# to print usage information for the parameters and
# exit.  Because setting this to true will interfere
# with the execution of a normal run, it is better to
# invoke this on the command-line using the 
# --help command-line parameter.
#
#"help" : false,

# The number of simulated users to be active in a run.
# The number of users must be at least 60.
#
#"users" : 1000,

# This parameter controls how much data is pre-loaded into the data services.
# It is the maximum number of simulated users that will be used when loading
# the data for this run.
#
#"maxUsers" : 1000,

# This parameter controls the  maximum run duration, in seconds, that needs 
# to be supported by the preloaded data.  If the current load won't support this 
# duration then the data will be reloaded. The default is 7200, equal to a steady-
# state of 2 hours.
#
#"maxDuration" : 7200,

# This parameter can be used to place a short description in the
# results CSV file, as well as in the output directory for the run.
#
#"description" : "",

# The length of a Weathervane run is specified by three time
# periods:
#   - rampUp: The duration of the ramp-up time specified in seconds.
#   	If the ramp-up time is too short, the server may 
#		experience errors due to login storms, and 
# 		the app-server JVM and other components may
# 		not be properly warmed-up.  
#   - steadyState: The duration of the steady-state portion
#   	of the run (in seconds).  Operation 
#		statistics are only collected during steady-state.
#   - rampDown: The duration of the ramp-down period in seconds.
#
# runLength is a shortcut for specifying the length of the run
# Allowable values (rampUp, steadyState, rampDown)
#  - short (120s, 180s, 60s)
#  - medium (720s, 900s, 60s)
#  - long ( 600s, 1800s, 120s)
# These values can be overridden by specifying values for the 
# rampUp, steadyState, and rampDown parameters.
#
#"runLength" : "medium",
#
# If any of rampUp, steadyState, or rampDown are specified
# their value will override the value set by runLength
#
#"rampUp" : 600,
#"steadyState" : 900,
#"rampDown" : 60,

# This is the number of workload instances to use.  A workload
# represents a set of workload drivers and a number of application
# instances whose load is driven by those drivers.
# It is also possible to explicitly define a list of workloads under
# the "workloads" parameter. If both "numWorkloads" and "workloads"
# are set, then the total number of workloads will be the sum of 
# numWorkloads and the length of the workloads list.
#
"numWorkloads" : 1,

# This is the number of application instances to use.  An 
# application instances represents an independent deployment 
# of an application.
# It is also possible to explicitly define a list of application
# instances under the "appInstances" parameter. If "numAppInstances"
# or "appInstances" are defined at the top-level, then they will apply 
# to all workloads.  If defined within a workload definition, then they apply
# only to that workload.  If both "numAppInstances" and "appInstances"
# are set, then the total number of application instances will be the sum of 
# numAppInstances and the length of the appInstances list.
#
"numAppInstances" : 1,

# The number of workload-drivers.  There is must be 
# at least one workload driver for each workload.
#
"numDrivers" : 1,


# Number of ConfigurationManagers
#
"numConfigurationManagers" : 1,

# Number of Elasticity Services
#
"numElasticityServices" : 0,

# Number of Coordination Servers
#
"numCoordinationServers" : 1,

# Number of front-end (before web tier or app tier) load balancers.
#
#"numLbServers" : 0,

# Number of web servers.
#
"numWebServers" : 1,

# Number of application servers 
#
"numAppServers" : 1,

# Number of message servers (1 or 2)
#
"numMsgServers" : 1,

# Number of file servers (0 or 1)
# If the imageStoreType is filesystem then this must be 1, 
# otherwise it must be 0.
#
#"numFileServers" : 0,

# Number of MongoDB servers
#
"numNosqlServers" : 1,

# If numNosqlServers is greater than 1, then the MongoDB deployment
# must either be sharded or deployed as a single replica set.  As a 
# result, either nosqlSharded or nosqlReplicated must be set to true
# to indicate to the run harness how it should configure MongoDB.
# 
#"nosqlSharded" : false,
# 
#"nosqlReplicated" : false,

# number of DB servers
#
"numDbServers" : 1,

# The number of Virtual Infrastructure hosts
#
#"numViHosts" : 0,

# In order to run the Auction application components inside 
# Docker containers, set useDocker to true.  If set at the top level it 
# will apply to all Auction services.  It can also be set in an explicit
# configuration at the level of individual workloads, application instances,
# service types or service instances.
#
# "useDocker" : false,

# Controls whether Docker containers should be pinned to CPUs on
# their host.  If true, the run harness interprets the parameter dockerCpuShares
# for each service to determine how many CPUs to use for that service.
#
# "dockerHostPin" : false,

# When Docker container pinning is enabled on a host, this parameter can be used
# to control whether all CPUs are used, on only even or odd numbered CPUs are used.
# Even or odd may be used to avoid using hyperthreads.
# Valid values: "all", "even", "odd"
#
# "dockerHostPinMode" : "all",

# This parameter corresponds to the cpu-shares parameter used when 
# starting a service's docker container.  If not explicitly set, the cpu-shares 
# parameter is not specified when starting that container and so that Docker default
# is used.
# When running service on which dockerHostPin is true, dockerCpuShares is interpreted as
# the number of CPUs to use for that service.
#
# "dockerCpuShares" : n/a,

# This parameter corresponds to the cpuset-cpus parameter used when 
# starting a service's docker container. You should not specify dockerCpuSetCpus for
# services running on hosts for which dockerHostPin is set to true. 
#
# "dockerCpuSetCpus" : n/a,

# This parameter corresponds to the cpuset-mems parameter used when 
# starting a service's docker container. 
#
# "dockerCpuSetMems" : n/a,

# This parameter corresponds to the memory parameter used when 
# starting a service's docker container. It sets the memory limit for 
# the service's Docker container
#
# "dockerMemory" : n/a,

# This parameter corresponds to the memory-swap parameter used when 
# starting a service's docker container. 
#
# "dockerMemorySwap" : n/a,

# This parameter corresponds to the net parameter used when 
# starting a service's docker container. 
# Valid values: "bridge", "host"
#
# "dockerNet" : "bridge",

# The runStrategy selects the objective of an invocation
# of run harness.  The default is "single", which causes
# the run harness to perform a single run and then exit.
# Other run-strategies are:
# - findMax : Selecting this strategy causes the run harness
# 	to perform runs until it has found the maximum number of 
# 	users that can be driven against the current 
# 	application deployment while satisfying the passing
# 	criteria. See the User's Guide for a complete description of the 
# 	maximum finding mode. The parameters that control the behavior of the 
# 	findMax strategy are described later in this file.
# - targetUtilization : This strategy causes the run 
# 	harness to perform multiple runs, adjusting the number
# 	of users in each run, in order to find the number of 
# 	users that drives the average CPU utilization of a 
# 	particular service tier to a specified target.
# 	See the User's Guide for a complete description of this
# 	mode.   The parameters that control the behavior of the 
# 	targetUtilization strategy are described later in this file.
# 
#"runStrategy" : "single",

# The runProcedure selects among various options for
# how individual runs are to be performed.  
# At present, the findMax and targetUtilization
# runStrategies require the use of the "full" runProcedure.
# The other options ("prepareOnly" and "stop") can only be 
# used with the single run strategy.  The runProcedures
# that can be specified are:
# - full: This runProcedure performs a complete run of 
# 	Weathervane each time it is invoked by the selected runStrategy.
# - prepareOnly: This run-procedure prepares all of the application
#	services, starts the Auction application, and then
#	exits.  It does not start the workload-driver.  This runProcedure
#	can be useful when debugging configuration and deployment
#	issues.  Once the application is running, you can manually
#	connect to the application using a web browser and examine
#	the state of the services to identify issues.
# - runOnly:
# - loadOnly:
# - stop: The stop run-procedure is used to stop a run that is 
#	already in progress.  Invoked from a separate command-line, 
# 	this will cleanly stop the workload and shut-down all of the 
#	application services.  It should also be used after running
#	with the prepareOnly run-procedure to ensure that all services
# 	are properly cleaned up before a new run.  For ease-of-use,
#	the run harness also provides a --stop command-line parameter,
#	which is a shorthand for for invoking this runProcedure.
#
#"runProcedure" : "full",

# The Logging level controls the amount of information that is 
# collected during a run and placed in the output directory
# for the run.  Each level also collects all data specified 
# in all lower levels.
# The log levels are as follows:
#  0 : The only data saved for a run is the results file and
#      the logs generated by the run script.
#  1 : After a run, copy over the log files from the 
#      application services.  
#  2 : Collect performance data on all workload-driver 
#    	 and application hosts.
#  3 : Collect performance stats from the workload-drivers 
#	   and all application services
#  4 : Collect performance data from all virtual-infrastructure hosts
#
#"logLevel" : 1,

# The redeploy parameter is used to control whether 
# the run harness removes old versions of the various 
# binaries and run artifacts and replaces them with updated versions.
# Redeploying is used after updating, and possibly rebuilding, the 
# Weathervane files.  It can also be used if you suspect something has been 
# corrupted or if you manually edited some file on one of the deployment
# services.  The files that are refreshed are: the executables for the 
# workload generator on all driver nodes, the static web-content on the 
# web and application servers, and the application executable on the
# application servers.
#
#"redeploy" : false,

# The loadDb parameter is used to control whether the run harness
# will load the data services when trying to do a run for which the
# data is not loaded at the proper scale.  When set to false, the 
# harness will exit rather than loading the data.
#
#"loadDb" : true,

# The reloadDb parameter is used to force the run harness to load
# the data services at the proper scale for the run even if they 
# are already loaded at the proper scale.  This parameter is useful
# when changing the configuration in such a way that the existing data
# is no longer valid.  Such situations include changing the number of 
# MongoDB shards or updating the version of Weathervane. It is also useful 
# if the data becomes corrupted for some reason. 
#
#"reloadDb" : false,

# The backup parameter is used control whether the run harness creates
# a backup of the data that is loaded into the data services.  This only 
# controls whether a backup is created just after the data is loaded.  To
# create a backup of already loaded data, use the rebackup parameter.
#
#"backup" : false,

# The rebackup parameter is used control whether the run harness creates
# a new backup of the data that is loaded in the data services, even if 
# a backup already exists.  This parameter is useful
# when changing the configuration in such a way that the existing data
# is no longer valid.  Such situations include changing the number of 
# MongoDB shards or updating the version of Weathervane.  rebackup may also be
# used to force the creation of a backup when the data has been loaded
# on a previous run.
#
#"rebackup" : false,

# If powerOnVms is set to true, the run harness will make sure that all of
# the VMs for the run are powered on.  For this to work, the VMs must be on
# the defined viHosts, and passwordless-ssh must be set up for all 
# virtual-infrastructure hosts.  "powerOnVms currently works only with vSphere.
#
#"powerOnVms" : false,

# If powerOffVms is set to true, the script will make sure that all of
# the VMs on the viHosts that are not needed for the run are powered off.
# For this to work, the VMs must be on the defined viHosts, and 
# passwordless-ssh must be set up for all virtual-infrastructure hosts.
# powerOffVms currently works only with vSphere.
#
#"powerOffVms" : false,

# The startStatsScript is the name of a shell script that should be 
# executed when the run reaches the start of the steady-state. This can 
# be used to start the collection of statistics that are not already 
# collected by the run harness.  The script is called with one parameter,
# which is the length of the steady-state in seconds.  The script will run 
# in its own process, and so does not have to return immediately.  If the 
# value of the parameter starts with a /, then it is taken to be the absolute
# path to the file.  Otherwise the location of the script file is assumed to 
# be relative to weathervaneHome. 
#
#"startStatsScript" : "",

# The stopStatsScript is the name of a shell script that should be 
# executed when the run reaches the end of the steady-state. This can 
# be used to stop the collection of statistics that are not already 
# collected by the run harness, or to collect up statistic or log files.
# The script will run in its own process, and so does not have to return 
# immediately.  If the value of the parameter starts with a /, then it is 
# taken to be the absolute path to the file.  Otherwise the location of 
# the script file is assumed to be relative to weathervaneHome. 
#
#"stopStatsScript" : "",

# This option controls whether the IP addresses assigned to 
# the www hostname are the actual IP addresses of the front-tier
# servers or are virtual IP addresses managed by Keepalived
#
#"useVirtualIp" : false,

# Controls which web server is used.
# Must be one of: httpd24, nginx
#
#"webServerImpl" : "nginx",

# Controls which database to use.  
# Must be one of: postgresql, mysql
#
#"dbServerImpl" : "postgresql",

# Controls which imageStore implementation to use.
# When set to mongodb, the images are store in MongoDB and
# no filesystem is used.  When set to filesystem, the images are stored 
# in the network filesystem and requests for images are served by the web server, 
# if present. When set to filesystemApp, the images are stored in the network 
# filesystem and requests for images are served by the app server. When set to 
# memory, images requests are handled by the app server, 
# which always returns the same image.  Image uploads are dropped by
# the app server.  The memory mode is only included to help debug 
# scalability issues, and does not represent a realistic mode of operation.
# Must be one of: mongodb, filesystem, filesystemApp, memory
#
#"imageStoreType" : "mongodb",

# Informs the harness of the virtual infrastructure that is used
# in the deployment.  This information is needed when using powerOnVms 
# or when collecting VI performance information (logLevel == 4).
# Currently only vsphere is supported.
#
#"virtualInfrastructureType" : "vsphere",


# viHostnames is a list of virtual infrastructure 
# (e.g. ESXi) hosts that will be used during the run.  This list is 
# used when collecting virtual infrastructure statistics (logLevel == 4) 
# and when powering up and down VMs (when powerOnVms == true).
#
#"viHosts" : [],

# The next set of parameters controls the behavior of
# the findMax run strategy. 

# The initialRateStep is the size of the increment by which 
# the number of users is initially increased or decreased when 
# using the findMax run strategy.
#
#"initialRateStep" : 1000,
#
# The minRateStep is the minimum size of the change that
# will be made in the number of users when running in 
# maximum finding mode.  This works best of the initialRateStep
# is a multiple of the minRateStep
#
#"minRateStep" : 125,
#
# Number of times to repeat once maximum has been found.
# This provides an easy way to get an idea of the variability at
# the max passing level
# 	 
#"repeatsAtMax" : 0,

# The next set of parameters controls the behavior of
# the targetUtilization run strategy. 

# The targetUtilization is the CPU utilization to which the 
# harness will attempt to drive the selected server tier.
# 
#"targetUtilization" : 70,

# When aiming for a target utilization, the
# targetUtilizationMarginPct gives the percentage around
# the utilization that is considered a match.  Setting this 
# margin too low may result in runs that never converge on 
# the target
#
#"targetUtilizationMarginPct" : 0.02,

# The targetUtilizationServiceType selects which service tier
# is used when determining the CPU utilization for the target.  
# The utilization used is the average utilization of all servers
# of that type as determined by the sar data.
# Allowable values are: lbServer, webServer, appServer, dbServer,
#  						msgServer, nosqlServer, fileServer
#
#"targetUtilizationServiceType" : "appServer",

# It is possible to tune the performance of the data
# loading process by adjusting the properties of the 
# dbLoader application.
#
# dbLoaderThreads controls the number of threads that are
# active in the dbLoader.  Work is spead among all threads.
#
#"dbLoaderThreads" : 6,
#
# The dbLoaderHeap adjusts the maximum heap size for the dbLoader
# program.
#
#"dbLoaderHeap" : "4G",

# The next set of parameters controls the tuning of the 
# workload driver.  The heap size in of the driverJvmOpts and 
# the number of driverThreads will need to be increased 
# as the number of simulated users gets large
#
# The maximum size of the Java heap for the driver
#"driverJvmOpts" : " -Xmx4g -Xms4g -XX:+AlwaysPreTouch ",
#

# Application Server tuning parameters 
#
# appServerJvmOpts defines the command-line options used
# for the JVM in which Tomcat/tcServer runs
#
#"appServerJvmOpts" : "-Xmx2G -Xms2G -XX:+AlwaysPreTouch",
#
# appServerThreads is the number of thread in the Tomcat Executor used
# by the HTTP connector
#  
#"appServerThreads" : 100,
#
# appServerJdbcConnections is the maximum number of connections in 
# the JDBC connection pool between each Tomcat server and the 
# relational database
# 
#"appServerJdbcConnections" : 101,

# Tuning parameters for httpd.
#"httpdKeepaliveTimeout" : 60,
#"httpdMaxKeepaliveRequests" : 100,
#"httpdMaxClients" : 0,
#"httpdThreadsPerChild" : 250,
#"httpdMinSpareThreads" : 25,
#"httpdMaxSpareThreads" : 300,

# Tuning parameters for nginx
#"nginxKeepaliveTimeout" : 60,
#"nginxMaxKeepaliveRequests" : 100,
#"nginxWorkerConnections" : 0,

# Tuning parameters for haproxy
#"haproxyMaxConn" : 0,

# Tuning parameters for MySQL
#"mysqlInnodbBufferPoolSize" : 0,
#"mysqlInnodbBufferPoolSizePct" : 0.75,
#"mysqlMaxConnections" : 0,

# Tuning parameters for PostgreSQL
#"postgresqlSharedBuffers" : 0,
#"postgresqlSharedBuffersPct" : 0.25,
#"postgresqlEffectiveCacheSize" : 0,
#"postgresqlEffectiveCacheSizePct" : 0.65,
#"postgresqlMaxConnections" : 0,

# For best performance, transparent huge pages should be 
# disabled on the hosts running MongoDB.  The run harness
# ensures that this is the case.  If you want to force the use
# of transparent huge pages, set mongodbUseTHP to true
#
#"mongodbUseTHP" : false,

# Tuning parameters for NFS
#"nfsProcessCount" : 32,
#"nfsRsize" : 65536,
#"nfsWsize" : 1048567,
#"nfsServerAsync" : true,
#"nfsClientAsync" : true,

# The statsInterval controls the frequency of statistics reports 
# for sar and esxtop. It is the reporting frequency in seconds.
#  
#"statsInterval" : 15,

# resultsFileName is the name of the csv file into which the
# run script places the summarized results of each run.
#
#"resultsFileName" : "weathervaneResults",

}