However, there’s a problem with EC2. A big one: performance. Bang for your buck. My friend James Golick (@jamesgolick) has often publicly talked about how crappy performance was on EC2, both in terms of CPU and IO. I knew he was right, but didn’t know how right he was really.

I recently found out about Joe’s Data Center, a low-cost dedicated hosting provider so I decided to give them a shot for a pet project I’m working on. They certainly don’t have the infrastructure of Amazon, but that’s a trade-off I can live with given the scope of my project. They have great reviews all over the interwebs so that made me feel at ease.

I leased one of the cheapest machines they are offering: a dual processor AMD Opteron SledgeHammer 2.2Ghz for $55/mo. I went crazy and added 2GB of Ram for an extra $10/mo. Total damage: $65. Roughly the same price as a small instance on EC2 (m1.small). The SledgeHammer is by today’s standards a pretty old and crappy CPU, but I figured it would be plenty for my needs.

I decided to run some benchmarks against an m1.small to see how “bad” the SledgeHammer really was. I stopped paying attention to CPUs the minute I bought my first Mac 6 or 7 years ago. All these fancy CPU names don’t mean much to me anymore.

After some Googling, I settled on UnixBench for my benchmarks. I didn’t need very precise or scientific numbers, just a ballpark to see what I was getting at Joe’s.

I WAS BLOWN AWAY!!! In a nutshell, my dedicated server is 10 times faster than an m1.small instance. TEN TIMES!!! For the same price! IO is also about 5 times faster  than EC2′s local storage. And as a bonus, I get 4GB of Ram instead of just 1.7GB.

After such a surprise, I decided to benchmark more expensive EC2 instance types to see how well my new best friend fares against my olf virtual friends. The results were equally surprising: my dedicated box is faster than a m1.large ($250/mo), faster than a m1.xlarge ($500/mo) and roughly as fast as a High CPU c1.xlarge ($500/mo). More explicitly, the c1.xlarge did ~50% better when running UnixBench with 8 threads, but the Opteron box is 50% faster when single threaded. Also, to get IO roughly equivalent to my dedicated box on EC2, you have to shell out $500/mo for a c1.xlarge. Even the m1.xlarge doesn’t cut it.

EDIT: Since publishing this article, I rented a EX 4S at Hetzner. It is effectively 58 times faster than an m1.small and has 32 GB of Ram. IO throughput is 29 times higher. All this for just $13 more a month.

Here’s a chart of my results (UnixBench index):

The raw numbers (including IO) can be found here: https://gist.github.com/1566734.

I’ll let you draw your own conclusions, but to me, it’s clear that Amazon needs to improve its performance. The bang-for-your-buck ratio of EC2 is completely out of whack.

EDIT: Title was initially “EC2 is basically one big scam”, which was a bad choice of word. I changed to word scam to rip-off, which is more appropriate I believe.

EDIT 2: Hetzner.de has a new amazing machine, the EX 4S (Intel Core i7 2600, 32 GB, 3TB RAID 1). It’s just ~$78/month so I decided to benchmark it as well. HOLY FUCKING SHIT. Check this out: Hetzner EX 4S Benchmarks. I added the numbers in the table above for comparison. Looks like we have a winner!

Don’t worry, there’s hope! I have saved the old black icon and you can return to the old school way pretty easily.

How to update Twitter for Mac’s icon from blue to black:

1. Download the Black Twitter Icon Pack
2. Navigate to your Applications folder
3. Right click Twitter and select Show Package Content
4. Go to Contents, then Resources
5. Update the file Icon.icns with the one included in the Black Twitter Icon Pack zip file.
6. Profit!

As a bonus, you’ll find an alternative icon that Twitter never used. You may use it if you wish.

Enjoy!

Alex Coles (@myabc) volunteered and is now the new maintainer. He already shared with me a couple good ideas for the site, which he’ll hopefully implement soon.

Thank you, Alex, and congrats!

HD Video on iTunes (missing the last 20-25 mins unfortunately):

MeshU - Part 1

MeshU - Part 2

• A quick recap of what I said.
• And Jonathan Keebler live-blogged the event at ScribbleLive.
• My slides:

I guess this is as close as it gets to being there in person! Looking forward to your comments!

I need to give credit to this page, without which I’d still be fighting with this whole thing.

This tutorial uses JRuby 1.2, Glassfish 2.1, Merb 1.0.10 and Ubuntu 8.04 LTS. To make my life easy, I simply fired an EC2 instance based on ami-71fd1a18. I recommend you do the same. However, it should work from just any vanilla Ubuntu 8.04.

Some important comments are in the script below, make sure to read them. Enjoy!

The process is not quite as straightforward as it should be, but it works pretty well.

The secret lies in a nifty application called ScreenRecycler.  In a nutshell, it allows you to use a monitor connected to a second computer as an additional monitor to your main computer.  So yes, you DO need 2 computers.  The good news is that the second computer can be either Mac, Windows or Linux. The bad news is that it’s slightly slower if the second computer is not a Mac. My second box is running Windows and it’s very usable for e-mail and calendaring. 

My setup consists of:

• 1 Dell 24″ 2405FPW (awesome monitor btw)
• 1 Samsung 22″ 2243BWX (vertical)
• 1 Unibody Macbook
• 1 custom-built PC

Screen configuration:

• Main screen: Pretty much everything happens on this screen
• Vertical screen (left): Mail.app (top), iCal (bottom)
• Macbook screen: Twhirl, Corporate MSN Messenger, Adium

The -really- cool thing about my setup is that, if I ever need to use Windows, I can just stop ScreenRecycler and my Windows desktop appears on my left screen.  Because I use SynergyKM (and this), I simply have to move my mouse to the left and my keyboard and mouse automatically start controlling Windows. 

For your information, clicking the image will let you see my setup it its full glory!

Here’s the link… http://startupcfo.ca/2009/02/startup-lessons-interview-with-carl.html

Ok, since you’re reading this, you’re probably already convinced of that so let’s jump to the meat.

Long story short, I had this paper document I wanted to send by email.  I could have done it in a dozen steps, but I felt lazy.  Here’s a trick I figured out to make it very quick and easy:

1. Fire up Image Capture.
2. Change Automatic Task to “Mail.app”.  To do so, click the dropdown menu, then “Other”, then browse to Mail.app in your Applications folder.
3. Give your document a name in “Name” and set all the other settings as necessary.
4. Hit overview/scan
5. Mail opens up automatically after the scanning process.  Just type in the email address of the recipient and you’re done!

Managing gems has been painful lately. Like most people, we’re freezing them, which helps tremendously. However, there’s a few problems with this approach:

• We can’t freeze C extensions because they need to be compiled for the target platform. We develop on OS X and Linux 64, but deploy to Linux i386. As a workaround, we currently freeze but recompile them on every deployment. Definitely not optimal.
• Our frozen gems directory is getting huge.
• It’s becoming complicated and quite a mess to manage multiple gem versions for different branches/tags.
• We never quite know which branch needs which gem.

Of course, we could manually install the gems we need on our servers. But the word “manually” generally leads to “epic fail”.

So I thought, why not install them at deployment time, just before restarting the Mongrels, with Capistrano? That seemed like a pretty good idea! The only problem is that Rubygems will always install a gem when asked to do so, even if it’s already installed.

That’s where install_gems.rb comes in. install_gems.rb takes a file name as an argument. This file contains a simple list of gems along with their version number. A custom installation command can also be specified.

Here’s an example:

# This is an example file. As you can see, it supports comments.
haml 2.0.3
eventmachine 0.12.2
# Notice the custom command specified after the --
termios 0.9.4 -- gem install termios -v 0.9.4 --no-rdoc --no-ri

To install the above gems, you’d simply run
./install_gems.rb input_file

install_gems.rb has a few advantages over vanilla rubygems:

• It will only install a gem if the specified version is not already installed. That’s obviously much faster than reinstalling everything every time.
• C extensions will be properly compiled.
• Using different gem versions in different branches/tags/releases is now very easy. You just have to maintain a list of required gems in your Git repository and make sure Capistrano runs install_gems.rb against this list before restarting the application servers.
• It forces us to keep an up-to-date list of the gems we need.

Of course, for this to work as expected, you’ll need to require specific gem versions in your application. Your production server will likely have multiple versions of the same gems installed and if you don’t specify which version of the gem you want to require, things might (or will) break.

I released install_gems.rb on GitHub and Daniel Haran has already submitted a patch. Feel free to do so as well, I’m a puller!