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