3 ms·

I've done AWS, dedicated, and colo. Each one has their own tradeoffs. AWS is daunting at first -- but then so is Debian. Once you figure out the keys thing and

by aristus 18y ago

I've done AWS, dedicated, and colo. Each one has their own tradeoffs. AWS is daunting at first -- but then so is Debian. Once you figure out the keys thing and your base image it's fairly easy (also see ElasticFox, S3Browser). You might as well learn it, even if you stick with dedicated hosting for other reasons. Things not to sneeze at: * elastic: start up a dozen servers in a few minutes * free access to s3 storage * crazy awesome pay-as-you-go bandwidth (250mbps) * expensive for the CPU/RAM you get * virtual disks can be slow on random seeks * sorry, no cPanel (though see RightScale) * poor locality of servers

anotherjesse 18y ago
related to an earlier post today about backup, S3 snapshots of the virtual disks provides easy backup (just make sure you have it setup right - eg, it isn't a backup solution unless you test restoration). Snapshots are also useful for testing new ideas, out of band processing (spin up an instance that processed data from a snapshot instead of hitting the main DB). Amazon consistently improves their offerings - so if it doesn't fit right now it might next month.
mdasen 18y ago
So, just to comment on the disk reads: the local, non-persistent disks don't offer great speeds (you're right). However, that shouldn't matter too much now. All of your application code should fit in memory once it's been read off the disk and so you shouldn't be hitting the local disks much after boot. Static files should be on S3 and databases should be stored on EBS. EBS has great performance. RightScale noted that they got over 70MB/s with sysbench and over 1000 I/O operations per second. If you want more performance, you can even stripe across EBS volumes. EBS really helped EC2's viability a ton. EC2 users now have access to cheap, reliable, and fast storage.
- aristus 18y ago
  I'll have to try it out, thanks. A quick search doesn't turn up any bonnie tests or similar, so I'll do them and put them online. (edit) this suggests that EBS is slower than the virtual disk for open/seek/write/flush: http://bizo-dev.blogspot.com/2008/11/disk-write-performance-on-amazon-ec2.html http://bizo-dev.blogspot.com/2008/11/disk-write-performance-...

by aristus 18y ago

anotherjesse 18y ago

related to an earlier post today about backup, S3 snapshots of the virtual disks provides easy backup (just make sure you have it setup right - eg, it isn't a backup solution unless you test restoration). Snapshots are also useful for testing new ideas, out of band processing (spin up an instance that processed data from a snapshot instead of hitting the main DB). Amazon consistently improves their offerings - so if it doesn't fit right now it might next month.

mdasen 18y ago

So, just to comment on the disk reads: the local, non-persistent disks don't offer great speeds (you're right). However, that shouldn't matter too much now. All of your application code should fit in memory once it's been read off the disk and so you shouldn't be hitting the local disks much after boot. Static files should be on S3 and databases should be stored on EBS. EBS has great performance. RightScale noted that they got over 70MB/s with sysbench and over 1000 I/O operations per second. If you want more performance, you can even stripe across EBS volumes. EBS really helped EC2's viability a ton. EC2 users now have access to cheap, reliable, and fast storage.

aristus 18y ago
I'll have to try it out, thanks. A quick search doesn't turn up any bonnie tests or similar, so I'll do them and put them online. (edit) this suggests that EBS is slower than the virtual disk for open/seek/write/flush: http://bizo-dev.blogspot.com/2008/11/disk-write-performance-on-amazon-ec2.html http://bizo-dev.blogspot.com/2008/11/disk-write-performance-...