This contains set of jar files developed during the thesis. They help to run and benchmark the service on the cloud. This readme gives basic hints, how to start the jar files from the command line. If interested running as a separate processes from command line, use "nohup command &". Nohup indicates no hangup. This might happen if you have connected to the terminal through network and timeout happens, it might kill the process started by the user. 

Most of the applications can be started without any parameters defined, but then defaults are used. These are tested by Ubuntu 11.04, bot other linux distros might work.
*************************************
HTTPServer.jar
	Is ment for downloading files from the web. User can define on which port it will listen incoming HTTP GET requests and which folder will be used to show the downloadable content.

	Usage: java -jar HTTPServer.jar 8080 10 /mnt true
		8080 - port, where the service is accessible
		10 - how many threads to support, connections
		/mnt - folder to be shown to the client, to not use trailing slash
		true - whatever files can be downloaded or not (forces download by sending specific header)

*************************************
ServerStatus.jar
	Is ment for gathering statistics from the local computer (running instance) and will start as a web service, that can be accessed from 5555 port to fetch the gathered statistics. Ubuntu needs to have sysstat package installed, otherwise it is not capable of gathering the statistics. This service can be accessed through web server, using localhost:5555/ or command: echo "STATS" | /bin/netcat -q 2 127.0.0.1 5555

	Usage: java -jar ServerStatus.jar 5555
		5555 - port, where the service is accessible

*************************************
CloudController.jar
	Is used to control the Amazon cloud for conducting the experiments. It will make initial configuration to running instance. There is several ways to configure the server list, one is by hand, when changing servers.txt file, defining IP addresses and roles for each server and the other is to use --configure --auto-configure, this will fetch already running servers from cloud, using key and instance AMI provided by the user. Configuration has to be correct in order to get it working. See configuration.txt and servers.txt to make modifications in the configuration files. Also look into configuration/commands/ folder to see, what commands for each instance role are going to be executed, while configuring the servers. Common.txt indicates, that these commands are started for all the instance roles.

	It also needs to have necessary files and folders included (that are in the same folder) to start the jar file, otherwise it fails, as it cannot read configuration from the files. It takes care of configure correct MySQL and memcached IP addresses to Apache back-end servers and updates nginx settings.

	Usage: java -jar CloudController.jar
		Will start the cloudcontroller in listening mode, it will collect performance metrics from the cloud and if user defined to allocate servers dynamically, it will ocasionally try to add or remove servers, depending which algorithm has been activated in the code.

	Usage: java -jar CloudController.jar --configure
		Will start the cloudcontroller in configuration mode, tries to configure servers defined in the servers.txt list and finish, when the configuration part is done.

	Usage: java -jar CloudController.jar --configure --auto-configuration
		Is same as previous, but will automatically fetch server list from the cloud. Make sure to later on delete extra APACHE servers from servers.txt, as they otherwise will be marked as STATIC and not allowed to remove by CloudController. For example, if you want to start the experiment with 10 Apache servers, but the load will decrease and at the end experiment, you have 5 Apache servers, remove at least 5 Apache servers from the list to allow removing the servers not proposed in the list.

*************************************
BenchMark.jar
	It is used to stress test the system (SUT - service under test). It is generating requests to front-end nginx load balancer server and keeps track of memcached hit ratio. It will output various information about response times into file and at the end, small summary of the response time and successful requests are printed into console.

	Usage: nohup java -jar BenchMark.jar --sut 192.168.1.60 --sut-port 80 --memcached 192.168.1.61 --memcached-port 11211 --prefix small_ --min-rps 1 --max-rps 5 --trace-repeats 1 --use-rdg false --url-file url.txt --curve-file ramp.curve --random-seed 0 --time 3600 --timeout 8000 > worker_output.txt &
	tail -f output.txt
	
		--sut - this is system, we want to stress test
		--sut-port - port, where the requests are sent
		--memcached - where the memcached server is running
		--memcached-port - in which port memcached is running
		--prefix - prefix of the output files
		--min-rps - what would be the smallest arrival rate in requests per second
		--max-rps - what would be the largerst arrival rate in requests per second
		--trace-repeats - how many times to repeat trace curve through the experiment
		--use-rdg - should be use random inter-arrival rate or not
		--url-file - where to fetch the request URI list
		--curve-file - where to fetch the trace curve
		--random-seed - what random seed to use, while generating the requests, 0 means that requests are taken sequentially
		--time - time in seconds to stress test the system
		--timeout - how many milliseconds the request is considered as timed out

		tail -f output.txt is used to see the latest output of the file output.txt

Ramp-up trace file example:
1
3
5
7
9

URI file example:
/mediawiki/index.php?title=Main_Page
/mediawiki/index.php?title=Combination

	Not all the parameters are needed to defined while using BenchMark.jar, as it would then use default parameters. Make sure trace and URI file exists, otherwise the program will not execute.
