Rackspace vs Amazon impressions

I’ve been a customer of Amazon Web Services since they have been in beta. I’ve also worked with Rackspace now and then. Lately I’ve been working extensively with Rackspace infrastructure so I have a better understanding of their products. Bellow there are a few things that bother me at Rackspace:


The thing you are going to use 99% of the time with any of the providers. Amazon offers normal instances, high cpu instances, high memory instances, huge memory and cpu instances. On Rackspace you will have a very limited offer of instances. No high cpu or high memory. They do have plans to add them in nearby future. Until then, if you have a CPU bottleneck then it’s tough luck: scale up the instance and pay double.

And since we are talking about pricing for instances, Amazon is cheaper on the long run due to Reserved Instances (you pay an upfront fee and lower price/hour for the instance after). Amazon has been cutting down prices several times. Rackspace? Never.

Block storage

Called EBS on Amazon or CBS on Rackspace, it’s the preferred way of adding extra space to running instances without upgrading them. Beware that on Rackspace it takes an horrible amount of time to do a snapshot. I had to contact RS support several times because of this.

MySQL instances

Called RDS on Amazon or Cloud Database on Rackspace, they are basically optimized instances that run MySQL, but you are not given SSH access to them. Here Rackspace has the worst offer:
no scheduled backups (RS recommends mysqldump … lol try to do mysqldump for 10GB+ of data)
no replication (really? I couldn’t replicate my database)
no hotspare (Amazon MultiA-Z)

The good thing about Cloud Database is that they are fast. Really fast. Also RS promised to address all the above things in the nearby future (yeah).

Load Balancing

Rackspace does not support LB inside private network. Come on RackSpace, do your homework. This thing has been working for AWS since ancient history.


There are many other things that need to be discovered, probably not pleasant ones. So far I am disappointed with Rackspace and what it has to offer and I would recommend to any customer to use Amazon instead.

Installing Scalr 3.5 Open Source on Ubuntu 12.04

This is an update on an older post of mine, one of my first articles regarding cloud computing. Much has changed since since 2008 when I have wrote this article “How to install Scalr on Ubuntu 8.10 EC2 Instance“.

For example the Ubuntu has evolved to 12.04 LTS (I am using LTS 64bit for this howto) and Scalr is now version 3.5. One thing didn’t change: it’s still a royal PITA to get Scalr open source working. Hopefully this howto will help you to install Scalr on your server. It doesn’t cover operating Scalr and other things, which I will address in future posts, if there is enough interest.

After you have installed Ubuntu 12.04 64bit server edition to your server or virtual machine the way you like it it’s time to start the update process:

apt-get update && apt-get upgrade

Now you are ready to run tasksel and select the following roles for your server: OpenSSH, DNS server, LAMP server

You will need to install some dev packages before going anything else:

apt-get install libcurl4-gnutls-dev make librrd-dev

Now it’s time for PHP5 related extensions:

apt-get install php5-curl php-gettext php-net-socket php5-mcrypt php-xml-serializer libssh2-php php-soap php5-snmp php5-rrd
pecl install pecl_http
echo "" >/etc/php5/conf.d/pecl_http.ini
pecl install rrd
echo "" >/etc/php5/conf.d/rrd.ini

Time to get Scalr code:

cd /tmp
tar zxvf scalr35
cd scalr-3.5.r7704
cp -r app /var/www/
chown -R www-data:www-data /var/www/app

Create new database and import sql from sql/scalr:

mysql -p
mysql> CREATE DATABASE scalr CHARACTER SET latin1 COLLATE latin1_swedish_ci;
mysql> grant all privileges on scalr.* to scalr@localhost identified by 'password';
mysql> flush privileges;
mysql> quit
mysql -p scalr <sql/scalr.sql

While doing that import I’ve got a nice error:
ERROR 1054 (42S22) at line 2222: Unknown column ‘architecture’ in ‘field list’
1) Drop database
2) Search sql/scalr.sql for “CREATE TABLE IF NOT EXISTS `role_images`” and add after platform:

`architecture` varchar(25) DEFAULT NULL,
`os_family` varchar(25) DEFAULT NULL,
`os_name` varchar(25) DEFAULT NULL,
`os_version` varchar(25) DEFAULT NULL,
`agent_version` varchar(25) DEFAULT NULL,


Configuration of Scalr is quite simple:

cd /var/www/app/etc
cp config.ini-sample config.ini
edit config.ini

Cron jobs required by Scalr? Just type crontab -e and add the following lines:

*/2 * * * * /usr/bin/php -q /var/www/app/cron-ng/cron.php --Poller
* * * * * /usr/bin/php -q /var/www/app/cron/cron.php --Scheduler2
*/10 * * * * /usr/bin/php -q /var/www/app/cron/cron.php --MySQLMaintenance
* * * * * /usr/bin/php -q /var/www/app/cron/cron.php --DNSManagerPoll
17 5 * * * /usr/bin/php -q /var/www/app/cron/cron.php --RotateLogs
*/2 * * * * /usr/bin/php -q /var/www/app/cron/cron.php --EBSManager
*/20 * * * * /usr/bin/php -q /var/www/app/cron/cron.php --RolesQueue
*/5 * * * * /usr/bin/php -q /var/www/app/cron-ng/cron.php --DbMsrMaintenance
*/2 * * * * /usr/bin/php -q /var/www/app/cron-ng/cron.php --Scaling
*/5 * * * * /usr/bin/php -q /var/www/app/cron/cron.php --DBQueueEvent
*/2 * * * * /usr/bin/php -q /var/www/app/cron/cron.php --SzrMessaging
*/4 * * * * /usr/bin/php -q /var/www/app/cron/cron.php --RDSMaintenance
*/2 * * * * /usr/bin/php -q /var/www/app/cron/cron.php --BundleTasksManager
* * * * * /usr/bin/php -q /var/www/app/cron-ng/cron.php --ScalarizrMessaging
* * * * * /usr/bin/php -q /var/www/app/cron-ng/cron.php --MessagingQueue
*/2 * * * * /usr/bin/php -q /var/www/app/cron-ng/cron.php --DeployManager
*/2 * * * * /usr/bin/php -q /var/www/app/cron/cron.php --UsageStatsPoller
* * * * * root /usr/bin/php -q /var/www/app/cron-ng/cron.php --SNMPStatsPoller

Time to add a Virtual Host:

cat <<EOF> /etc/apache2/sites-available/scalr
<VirtualHost *:80>
DocumentRoot "/var/www/app/www"

<Directory "/var/www/app/www">
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all

Enable required Apache modules and site and restart everything:

a2ensite scalr
a2enmod rewrite
service apache2 restart

DNS managed by bind9:

chmod g+w /etc/bind/named.conf
echo 'include "/var/named/etc/namedb/client_zones/zones.include";' >> /etc/bind/named.conf
mkdir -p /var/named/etc/namedb/client_zones
chown root.bind /var/named/etc/namedb/client_zones
chmod 2775 /var/named/etc/namedb/client_zones
echo ' ' > /var/named/etc/namedb/client_zones/zones.include
chown root.bind /var/named/etc/namedb/client_zones/zones.include
chmod g+w /var/named/etc/namedb/client_zones/zones.include

To get rid of nasty AppArmor warnings and errors edit /etc/apparmor.d/usr.sbin.named and add:

/var/named/etc/namedb/client_zones/zones.include rw,

And finish it by restarting AppArmor and bind9:

service apparmor restart
service bind9 restart

Open your browser and go to Default username/password: admin/admin.

If you have issues or you need more info please feel free to comment 🙂

Apache2 worker vs prefork for ISPConfig benchmark

I’ve been running ISPConfig latest version(3.0.4) on Amazon cloud t1.micro instance for some time to host several small sites, mostly WordPress. I’m quite happy with the performance of the instance. The OS is Ubuntu 10.04 LTS. Until recently I’ve used the default mpm which is prefork, but I decided to test out worker also. If you are wondering I use mod_fcgid for all the sites. That being said I performed several tests with ab (apache benchmark) to see which mpm can server most requests per second.

While I do not claim this is the best setup, I think worker is better suited for me. Some people said they had problems because of mpm worker. So far so good, but will update this post if there are any issues.

Test results:

Concurrency Level: 32
Time taken for tests: 7.834 seconds
Complete requests: 5000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 4972
Total transferred: 84831033 bytes
HTML transferred: 83206915 bytes
Requests per second: 638.27 [#/sec] (mean)
Time per request: 50.136 [ms] (mean)
Time per request: 1.567 [ms] (mean, across all concurrent requests)
Transfer rate: 10575.21 [Kbytes/sec] received
Concurrency Level: 32
Time taken for tests: 7.096 seconds
Complete requests: 5000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 4968
Total transferred: 84877824 bytes
HTML transferred: 83247322 bytes
Requests per second: 704.63 [#/sec] (mean)
Time per request: 45.414 [ms] (mean)
Time per request: 1.419 [ms] (mean, across all concurrent requests)
Transfer rate: 11681.17 [Kbytes/sec] received

Creating consistent backups for EBS with EXT4 and quota

What’s this about?
Data security and backups are very important aspects when you work with servers, especially if you are using cloud infrastructure. I am using AWS(Amazon Web Services) as my preferred IaaS, so the following how-to is tailored for Amazon EC2 instances using EBS as storage for the web sites files. On my instance I have Ubuntu 10.04 LTS installed and on top of it I run ISPConfig 3.0.4(latest version at the moment I write this article). Some of the programs required to run this setup were already installed, but it should be pretty obvious if you miss anything. If you need help you can either leave a comment or contact me via email.

The following setup will allow you to create an EBS using EXT4 as file system, with quota enabled on it(for ISPConfig) and weekly backups of the EBS. In case of instance failure you should be able to launch a new instance and attach the EBS, without losing any web sites files. In case of EBS failure you can recreate one from the most recent snapshot.

Create an EBS in the same zone as your instance and attach it to your instance as /dev/sdf. This can be easily done from AWS Management Console.

Install xfsprogs

sudo apt-get install xfsprogs

Create EXT4 filesystem on /dev/sdf

sudo mkfs.ext4 /dev/sdf

Now mount it temporarily

sudo mkdir /mnt/ebs
sudo mount /dev/sdf /mnt/ebs

Stop the apache2 web server and copy the files to /mnt/ebs

sudo service apache2 stop
cd /mnt/ebs
sudo cp -rp /var/www/* .

Prepare quota

touch quota.user
sudo chmod 600 quota.*

Add the entry to /etc/fstab

/dev/sdf /var/www ext4 noatime,nobootwait,usrjquota=quota.user,,jqfmt=vfsv0 0 0

Unmount the EBS and remount it to /var/www

sudo umount /dev/sdf
sudo mount /dev/sdf /var/www -o noatime,usrjquota=quota.user,,jqfmt=vfsv0

Enable quota

sudo quotacheck -avugm
sudo quotaon -avug

Start the apache2 web server and check that the web sites are working properly

sudo service apache2 start

Install ec2-consistent-snapshot script for weekly backups of EBS

sudo add-apt-repository ppa:alestic
sudo apt-get update
sudo apt-get install -y ec2-consistent-snapshot

Prepare first snapshot(I assume the cron will run as root user, hence I create the awssecret file in /root directory)

sudo touch /root/.awssecret
sudo chmod 600 /root/.awssecret

Edit .awssecret and add following lines, in this order, replacing ACCESS_KEY_ID and SECRET_ACCESS_KEY with your own, both can be found under Account->Security Credentials:


Test the snapshot creation with debug mode activated, replace VOLUME_ID with the right volume ID:

sudo ec2-consistent-snapshot --debug --description "snapshot $(date +%Y-%m-%d-%H:%M:%S)" --freeze-filesystem /var/www vol-VOLUME_ID

If everything went well you should be able to see your new snapshot in the AWS Management Console.

Finally add this to your root crontab (by running sudo crontab -e):

@weekly /usr/bin/ec2-consistent-snapshot --debug --description "snapshot $(date +'%Y-%m-%d %H:%M:%S')" --freeze-filesystem /var/www vol-VOLUME_ID>>/var/log/backup.log 2>&1

Make sure you put the correct VOLUME_ID!

This should be all, you now have all your web sites on EBS, quota is enabled and weekly backups enabled. I think I pretty much nailed everything you need in order to perform this setup, but if there are any issues feel free to leave a comment. Also I love getting feedback so if you found this article useful leave a comment also 🙂

Mysql benchmark: RDS vs EC2 performance

the setup: 1 m1.small ec2 instance vs 1 db.m1.small rds instance, tests are being run from the m1.small instance. The goal is to determine how the site will perform when moving the database from localhost to a remote instance.

I used sysbench for mysql benchmarks. On a linux server running ubuntu 10.04 you can simply install it with the following command(it’s obvious but just in case):

sudo apt-get install sysbench

The first tests performed were m1.small EC2 instance running mysql-server 5.1.41-3ubuntu12.8 VS RDS instance type db.m1.small running mysql server 5.1.50. The test database had been set to 10 000 records, number of threads = 1, test oltp.

sysbench --test=oltp --mysql-user=root --mysql-password=password --max-time=180 --max-requests=0 prepare
sysbench --test=oltp --mysql-user=root --mysql-password=password --max-time=180 --max-requests=0 run

The results

m1.small EC2 instancedb.m1.small RDS instance
OLTP test statistics:
queries performed:
read: 263354
write: 94055
other: 37622
total: 395031
transactions: 18811 (104.50 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 357409 (1985.56 per sec.)
other operations: 37622 (209.01 per sec.)
Test execution summary:
total time: 180.0044s
total number of events: 18811
total time taken by event execution: 179.7827
per-request statistics:
min: 4.04ms
avg: 9.56ms
max: 616.04ms
approx. 95 percentile: 38.42ms
OLTP test statistics:
queries performed:
read: 188230
write: 67225
other: 26890
total: 282345
transactions: 13445 (74.67 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 255455 (1418.74 per sec.)
other operations: 26890 (149.34 per sec.)
Test execution summary:
total time: 180.0573s
total number of events: 13445
total time taken by event execution: 179.9174
per-request statistics:
min: 9.08ms
avg: 13.38ms
max: 904.58ms
approx. 95 percentile: 20.99ms

As you can see the EC2 can perform 40% more transactions than the RDS instance. Nothing unexpected so far.

Time to move on and increase the number of threads to 10

m1.small EC2 instancedb.m1.small RDS instance
OLTP test statistics:
queries performed:
read: 264866
write: 94545
other: 37818
total: 397229
transactions: 18899 (104.97 per sec.)
deadlocks: 20 (0.11 per sec.)
read/write requests: 359411 (1996.22 per sec.)
other operations: 37818 (210.05 per sec.)

Test execution summary:
total time: 180.0462s
total number of events: 18899
total time taken by event execution: 1799.9289
per-request statistics:
min: 4.08ms
avg: 95.24ms
max: 2620.70ms
approx. 95 percentile: 445.91ms

OLTP test statistics:
queries performed:
read: 343812
write: 122772
other: 49109
total: 515693
transactions: 24551 (136.18 per sec.)
deadlocks: 7 (0.04 per sec.)
read/write requests: 466584 (2588.13 per sec.)
other operations: 49109 (272.41 per sec.)

Test execution summary:
total time: 180.2788s
total number of events: 24551
total time taken by event execution: 1801.8298
per-request statistics:
min: 13.41ms
avg: 73.39ms
max: 1126.02ms
approx. 95 percentile: 143.83ms

In this test the small RDS instance is faster than the EC2, 136 vs 105 transactions per second. I’ve also benchmarked a large RDS instance (the next one available after db.m1.small) and it got 185 transactions per second. Quite good, but the price is 4x higher.

The next test was performed vs a 10 million records, 16 threads. This time I only benchmarked a small and a large RDS instance. The large instance managed to do 228 transactions per second while the small one got a decent score of 127 transactions. One thing I noticed during this test is that the small instance started to use it’s swap, while the large one did not have this issue. This is probably due to the fact that 10M records db is aprox 2.5GB and the small RDS only has 1.7GB of RAM.

So if you are planing to grow and want an easy way to do it, switching your database to its own RDS is one of the first things you should consider. One of the immediate effects you will notice is that the CPU usage on the EC2 instance will be greatly reduced, leaving more power for the web server. You can easily increase the size and capacity of the RDS instance with just a few clicks. The backups are done automatically, which is great considering how many times I had to recover databases.

Amazon announces Free Usage Tier

Beginning from 1st of November you will be able to run a micro instance on Amazon cloud for free. Micro instance has 613 MB memory, up to 2 ECU(for short period bursts),32/64 bit platform and only has access to a 10 GB EBS(provided also for free). Also you get 5 GB to use with S3(simple storage) which is great for saving images (for example) and 30 GB data transfer(15 GB in and 15 GB out).

I believe this is a great opportunity to see what AWS is and also you may start to develop applications for cloud. You will probably want to use the EBS for MySQL storage and the S3 for media files.

Make sure you read all about this on their site before you use it and note that if you exceed the micro instance limits you are going to pay per use. Although the rates are low it never hurts to double check if you want to stay at 0$/month.

Once this offer is available (starting from 1st November) I am going to start testing a lot of stuff like how WordPress performs on this instance and how to install it so make sure you visit my blog from time to time! If you are interested in certain software installation on the amazon cloud platform feel free to send me an email and I will see if I can help.

mEgo is sky high

Yes ladies and gents, it is true! mEgo Inc, my former company where I have worked for the last 2 years as sysadmin, made the move to Amazon Elastic Compute Cloud (aka EC2) today!!!11oneone It’s a moment of great joy to see this thing happening now at the beginning of 2010.

Best wishes to the mEgo team!

LE: Proof

PING ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=48 time=10.6 ms

ISPConfig3 running on Ubuntu 9.10 on AWS

This is an idea on how to set ISPConfig 3 on Amazon EC2 for web hosting. It’s still work in progress and I await for any constructive feedback. Since English is not my first language there might be some grammatical errors.


  • AWS Account
  • Some Linux experience

Part I – Setting up AWS

I have done all the setup of instance and ebs from the Amazon Management Console. It has a very intuitive interface and it’s so easy to work with.

Optional: You can purchase reservation for an instance if you are planing to run it 24/7. To do so go to Instances -> Reserved Instances and click on Purchase Reserved Instance. For example a c1.medium instance reservation for 1 year costs 455$ one time fee and the hourly cost of the instance goes to 0.06$/hour. It’s your decision, do the math if it’s worth it or not to go with reserved instances.

  1. From the Management Console go to Volumes and Create Volume. I created a 40 GB volume in us-east-1a zone, choose an appropriate value for your needs.
  2. Next step which is also optional is to get an Elastic IP for your instance. Go to Elastic IPs and click Allocate New Address.
  3. You will need a keypair to access your instance. You can create one before launching the instance or create one when you also setup the new instance. Your choice. I created one before by going to Key Pairs -> Create Key Pair.

Part II – Launching the instance

Instance type used was c1.medium, the AMI for it was Ubuntu 9.10 Karmic 32bit ami-1515f67c from Canonical Images for Amazon EC2.

Go to Instances and press Launch Instance and make sure you set it to use ami-1515f67c. If you need to use a different zone or a 64 bit instance you can check the alestic page which is a wonderful resource for Ubuntu images for EC2. I would also suggest to join their EC2 Ubuntu Google Grup if you are serious about AWS + Ubuntu.

After the instance is up and running attach the Elastic IP and the Volume you have created to it. To attach the IP go to Elastic IPs and select Associate, for the EBS go to Volumes. I attached the EBS as /dev/sdb to the instance.

Later Edit: You will need to also modify the Security Groups and permit access on ports 22(SSH), 80(HTTP), 8080(ISPConfig 3), 20-21(FTP) -> still need more work to support PASV.

Part III – Install ISPConfig 3

Before proceeding with ISPConfig 3 setup connect to your instance and update the packages.

sudo su
apt-get update
apt-get upgrade

Note: You will have to connect to your instance using the ubuntu username and the key pair you generated for that instance. It won’t allow you to connect directly as root.

To install the ISPConfig 3 I followed the HowtoForge excellent tutorial with a small exception: I skipped the part of setting up the quota since I was planning to use the EBS as storage for sites and MySQL databases. The rest of the tutorial was just perfect.

Part IV – Setting up the EBS and ISPConfig to work with it

Most of the stuff and talk about EBS and MySQL snapshots is discussed on Amazon developer forums in the thread called Tutorial: Running MySQL on Amazon EC2 with EBS (Elastic Block Store). Make sure you read the discussion before or after you are done with this post.

apt-get install dmsetup
modprobe dm_mod
modprobe dm_mirror
modprobe dm_snapshot
mkdir /dev/.static/dev/mapper -pv

Create ext3 filesystem:

mkfs.ext3 /dev/sdb

Setup it with dmsetup

echo 0 `blockdev --getsize /dev/sdb` linear /dev/sdb 0 | dmsetup create ebs

Add the records to fstab

echo "/dev/mapper/ebs /ebs ext3 noatime,usrjquota=aquota.user,,jqfmt=vfsv0 0 0" >> /etc/fstab

Setup quota

touch /ebs/aquota.user /ebs/
chmod 600 /ebs/aquota.*
mount -o remount /ebs

Enable quota on ebs

quotacheck -avugm -F vfsv0 /ebs
quotaon -avug /ebs

For websites:

mkdir /ebs/sites
ln -s /ebs/sites /var/www/clients


Set Jailkit chroot home: /ebs/home/[username]

mkdir /ebs/home


/etc/init.d/mysql stop
mkdir /ebs/mysql/data /ebs/mysql/log -pv
mv /var/lib/mysql /ebs/mysql/data
ln -s /ebs/mysql/data/mysql /var/lib/mysql
mv /var/log/mysql /ebs/mysql/log
ln -s /ebs/mysql/log/mysql /var/log/mysql

To make a snapshot of the database, go to the mysql console (msqyl -p)

SYSTEM dmsetup suspend /dev/mapper/ebs

Take your snapshot of the EBS

SYSTEM dmsetup resume /dev/mapper/ebs

Note:This is still work in progress, any advices on how to improve it are greatly appreciated and any constructive criticism also.

More Apache benchmarks using EC2 instances

Back with more benchmarks … This time I’ve tested several EC2 instances, using the AMIs provided by scalr for application roles(app and app64). Site used for testing was mEgo.
c1.medium results:

Concurrency Level: 200
Time taken for tests: 311.715596 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 306810000 bytes
HTML transferred: 303610000 bytes
Requests per second: 32.08 [#/sec] (mean)
Time per request: 6234.312 [ms] (mean)
Time per request: 31.172 [ms] (mean, across all concurrent requests)
Transfer rate: 961.19 [Kbytes/sec] received

m1.large results:

Concurrency Level: 200
Time taken for tests: 420.241673 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 308313369 bytes
HTML transferred: 305097689 bytes
Requests per second: 23.80 [#/sec] (mean)
Time per request: 8404.834 [ms] (mean)
Time per request: 42.024 [ms] (mean, across all concurrent requests)
Transfer rate: 716.46 [Kbytes/sec] received

c1.xlarge results:

Concurrency Level: 200
Time taken for tests: 70.404865 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 306810000 bytes
HTML transferred: 303610000 bytes
Requests per second: 142.04 [#/sec] (mean)
Time per request: 1408.097 [ms] (mean)
Time per request: 7.040 [ms] (mean, across all concurrent requests)
Transfer rate: 4255.66 [Kbytes/sec] received

m1.xlarge results:

Concurrency Level: 200
Time taken for tests: 215.153753 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 308098602 bytes
HTML transferred: 304885162 bytes
Requests per second: 46.48 [#/sec] (mean)
Time per request: 4303.075 [ms] (mean)
Time per request: 21.515 [ms] (mean, across all concurrent requests)
Transfer rate: 1398.43 [Kbytes/sec] received

So to sum things up:
c1.medium can serve about 32 requests per second for 0.20$ per hour.
m1.large can serve less than c1.medium, around 24 requests per second for 0.40$ per hour … not nice 🙁
m1.xlarge can serve 47 requests per second, but it will cost you 0.80$ per hour.
The champion is c1.xlarge can serve 142 requests per second at same price as m1.xlarge, 0.80$ pe hour.

I didn’t include m1.small benchmarks, but from a previous post I can tell you it only server 6 requests per second, not a worthy instance.

My advice would be to go with c1.medium instances since they offer best price/performance ratio. But do the math for yourself!

MySQL benchmarks using Amazon EC2 instances

Here are some tests I’ve run on Amazon using AMIs provided by scalr for the mysql role. I’ve used the benchmark scripts supplied by MySQL located in /usr/share/mysql/sql-bench. I had to install a package before running the tests:

apt-get install libdbd-pg-perl

After that everything was simple:

root@ec2# mysql
mysql> create database test;
mysql> quit;
root@ec2# cd /usr/share/mysql/sql-bench
root@ec2# perl run-all-tests --dir='/root/'

For EBS tests I’ve done the following:
-created 1GB EBS volume in scalr
-attached it to the instance I was testing
-notice the device name (/dev/sdb for example)

root@ec2# apt-get install xfsprogs
root@ec2# mkfs.xfs /dev/sdb
root@ec2# mkdir /mnt/storage
root@ec2# cp -R /var/lib/mysql /mnt/storage/
root@ec2# chown mysql:mysql -R /mnt/storage/mysql

-edit /etc/mysql/my.cnf and change datadir from “/var/lib/mysql” to “/mnt/storage/mysql”
-restart mysql server and start the tests:

root@ec2# /etc/init.d/mysql restart
root@ec2# mysql
mysql> drop database test;
mysql> create database test;
mysql> quit;
root@ec2# cd /usr/share/mysql/sql-bench
root@ec2# perl run-all-tests --dir='/root/'

Instances types used and their codes:

m1.small(0.10$/hour) – Small Instance (Default) 1.7 GB of memory, 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit), 160 GB of instance storage, 32-bit platform

m1.large(0.40$/hour) – Large Instance 7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of instance storage, 64-bit platform

c1.medium(0.20$/hour) – High-CPU Medium Instance 1.7 GB of memory, 5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each), 350 GB of instance storage, 32-bit platform

c1.xlarge(0.80$/hour) – High-CPU Extra Large Instance 7 GB of memory, 20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each), 1690 GB of instance storage, 64-bit platform

EC2 Compute Unit (ECU) – One EC2 Compute Unit (ECU) provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.

seconds usr sys cpu tests
m1.small 1823 196.54 28.66 225.2 3425950
m1.small+ebs 1646 197.18 29.61 226.79 3425950
m1.large 1072 157.06 26.97 184.03 3425950
m1.large+ebs 1088 154.23 25.23 179.46 3425950
c1.medium 902 131.18 25.63 156.81 3425950
c1.medium+ebs 901 130.76 28.84 159.6 3425950
c1.xlarge 704 123.31 32.8 156.11 3425950
c1.xlarge+ebs 781 121.02 29.52 150.54 3425950

Bellow you can see a nice chart with how much time it took for each instance to finish the benchmark tests. Either I did something terribly wrong or EBS doesn’t improve MySQL performance.