Ben Noland's Blog

It’s better to introduce complexity into your code “Just in Time” rather than “Just in Case”.

Let’s make this ultra flexible, Just in Case someone wants to do x, y and z.
Let’s split this into a new library, Just in Case we need it elsewhere.
Let’s optimize this piece of code, Just in Case it’s too slow.

They’re really going to want a, b or c (not x, y and z).
It’s easy to create that new library later, when you know you need it.
A profiler will tell you what parts are slow.

If all the Just in Cases were saved until Just in Time… there would be time to refactor, there would be time to do more testing and the code would be more maintainable.

You should think about the Just in Cases, but don’t implement them yet… (unless it has to do with testing).

A few weeks ago, I decided it was time to move collabedit off of shared hosting. Shared hosting is great for small stuff, my blog is still here, but it wasn’t working well for the frequency of database interaction that collabedit needs. Collabedit doesn’t need much processing power, but whenever my shared hosting neighbors decided to exercise the cpu, things got very slow.

I looked at a few options, but ended up going for ec2. It gave me more familiarity and flexibility than app engine, has better pricing than dedicated hosting, and has a good community knowledge base.

I needed to run MySQL [1,2], python2.6, tornado, nginx (as a front end load balancer) and some cron jobs. I don’t need much horsepower, so I decided to try the micro instance (~$14/month). I got everything setup and ran it in test for a couple weeks. Everything worked great. The average request was 3X faster than the shared hosting environment.

Everything looked awesome, so on Feb 5 I moved it all over. The micro instance performed wonderfully… , for a few hours, then it didn’t. It was still working, everything was up, but it was very slow, and my cpu was at 99%. I spent hours looking at all my logs and tweaking indexes, but I couldn’t figure it out. It would run fast for awhile, and then it would slow wayyyy down. Requests were taking 60X longer than normal.

Then I re-read amazon’s description of the Micro Instance.

Instances of this family provide a small amount of consistent CPU resources and allow you to burst CPU capacity when additional cycles are available. They are well suited for lower throughput applications and web sites that consume significant compute cycles periodically.

I moved everything from the Micro Instance to a Small Instance. This fixed everything. Apparently I was experiencing the burst speed on the micro instance for the duration of my testing. It wasn’t until I put some real load on it that it switched out of turbo mode. Luckily the upgrade from Micro to Small only took about 10 minutes. Since MySQL is using the Elastic Block Storage, I just attached the EBS volume to the new instance all my data was there.

So, if you’re considering moving to a micro instance, makes sure to do some load testing before making the final decision. Ec2 is amazing, the transition has been very smooth other than that.

I was given a new machine at work today.  It’s an AMD Phenom II X4 965 running at 3.41 GHz, with 4.00 GB or RAM. The operating system is Windows XP Professional x64 Edition.

Here’s a list of the programs that I installed:

• firefox
• launchy
• netbeans 6.7
• python
• ipython
• java
• winmerge
• gvim
• winsplit revolution
• autohotkey
• tortoise svn
• cygwin

Some others I installed later:

• winamp