To test aspects like the time that a server takes to become available there two approaches can be used:
1) Manually laborious launch the instance creation order (from web or from API call) and start the counter of a chronometer
Then keep refreshing for the instance id to get the public dns name, or Ip, and then ping to know when the interface is up, then keep trying to access via ssh.
Stop the chronometer…
2) Go more pro and automate test through Cloud-Init procedure
That’s specifying your script, that will be executed when the instance starts.
This is done in Amazon through the User data.
There you can provide your scripts in plain text, in base64, or add as a file and they are executed as root.
In our case I created my scripts to automate tests and save time, while being more accurate.
Sample User data script for cmips tests:
#!/bin/sh # cmips v.1.0.3 cloud init execution tests # Define routes file_name=cmips-speed-test.000 # Complete Path, on cloud-init through user data $HOME is empty, so data will be at / # user data script is executed as root, so no problem of permissions file_route=$HOME/$file_name # Get the time when the server is up date_server_up=`date +"%Y-%m-%d %k:%M:%S:%N"` date_server_up_unix_time=`date +"%s"` # In case invoked from command line, show some info echo "Using logfile $file_route.log Server up: $date_server_up Unix Time: $date_server_up_unix_time" echo "-----------------------------------------------------------------------------------" >> $file_route.log echo "Server up: $date_server_up Unix Time: $date_server_up_unix_time" >> $file_route.log # Add packages you want apt-get install htop >> $file_route.log apt-get install git >> $file_route.log # Here you can add packages like mysql, apache, php... and monitor the time # You can also clone from github your source code to deploy your web $date_end_packages_install=`date +"%Y-%m-%d %k:%M:%S:%N"` $date_end_packages_install_unix_time=`date +"%s"` echo "Package finished installing at $data_end_packages_install Unix Time: $date_end_packages_install_unix_time" >> $file_route.log # Do Connection Speed tests # ... # Do cmips tests # ... # Get start of time for disk speed calculations date_start_dd_unix_time=`date +"%s"` date_start_dd=`date +"%Y-%m-%d %k:%M:%S:%N"` echo "Starting cmips dd tests at $date_start_dd Unix time: $date_start_dd_unix_time" echo "Starting cmips dd tests at $date_start_dd Unix time: $date_start_dd_unix_time" >> $file_route.log dd if=/dev/zero of=$file_route bs=4M count=64 >> $file_route.log ; sync date_end_dd_unix_time=`date +"%s"` date_end_dd=`date +"%Y-%m-%d %k:%M:%S"` total_seconds=`expr $date_end_dd_unix_time - $date_start_dd_unix_time` echo "Ending cmips dd tests at $date_end Unix time: $date_end_dd_unix_time Total seconds dd with sync: $total_seconds" echo "Ending cmips dd tests at $date_end Unix time: $date_end_dd_unix_time Total seconds dd with sync: $total_seconds" >> $file_route.log
In /var/log you can find the cloud-init.log file and examine it in deep if you’re curious.
I use dd to get data about disk performance. Is not so evident in Cloud, as all the Virtual platforms cache the file I/O from the guest instances, so tests with smalland medium-sized files are not trustworthy, and so certain aspects have to be taken in count:
- Test with big files: 1 GB or bigger
- Use block-size 4 MB at least
- Use sync, and calculate the real time it takes to release (even if is the Host and not the guest who controls that, it brings more accurate results)
- Do several tests, can have disparity in results
- Use /dev/zero . To really prevent caching I would prefer to use /dev/urandom but it really slows the tests and distort the results