Now one would expect that since you are paying the same amount of money to Amazon for each server instance created of this same type and size, that you should be getting the same performance out of each one. Sadly, that is a very wrong assumption, as our sys admin found out.

It turns out that the underlying hardware for each instance created impacts the actual performance that each instance gives you, even though the instances are all virtualized and marketed by Amazon as if they are all created equal. In our case, we found that the different underlying hardware that the virtual instance sits on has a significant impact on application performance, at least with respect to MySQL database performance. Instances that were created on machines with AMD’s Opteron 270 processors (2ghz 1mb L2 cache) showed significantly poorer MySQL performance compared to instances created on machines with Intel’s Xeon e5430 processors (2.66ghz 6mb L2 cache). Well, the hardware techies among you out there might be saying “well duh… of course the Xeon will spank with the Opteron, tell me something I don’t already know.” But that’s not the point.

The point is in both cases, the EC2 customer is paying the same for an instance that is marketed as having identical compute units (i.e. processing power), but the reality is very different. Bear in mind that one cannot select what underlying hardware you want your instances to be powered up on – what we did was simply keep destroying and creating new instances until we found that the new instance was created on the Xeon-based hardware that we wanted (TIP: from the Linux shell of the new instance, run this to see what hardware your instance was created on: cat /proc/cpuinfo).

Moral: while cloud computing with Amazon (or likely any other vendor of this ilk) has definite pluses, there are hidden gotchas that they don’t tell you about.

On to the solution: A modified version of memcached found here:

http://code.jellycan.com/memcached/

I don’t know why this does work, but I know it does and that’s good enough for me!

Here’s Google’s official word on this.

I found one workaround that suggests creating a new profile and applying a filter for just that country you are interested in – so basically all the stats within that profile report will be for that one country by default, giving you naturally uniques for that country. The limitations with this workaround is that for one, it will only apply to new data from that point forward as new profiles do not operate on past data already collected, and secondly, you need to create a new profile for every country you have an interest in having this data for. Rather cumbersome but I guess better than nothing.

If you have the list stored in a MySQL database, this little snippet will get the job done easily:

SELECT avg( (year( now() ) – year( [birthdate] ) ) + (DAYOFYEAR( now() ) > DAYOFYEAR( [birthdate] ) ) ) FROM [tablename]

Note: you need to replace [tablename] with the actual tablename (without the square brackets of course) and [birthdate] with the actual name of the column in your [tablename] in which you store the birthdate.

So what’s going on here?

Here’s the breakdown of what it’s doing:

Step 1 – We calculate each member’s age by subtracting the year we are now in from the year of their birth: year( now() ) – year( [birthdate] )
Step 2 – We check if as of right now, that person’s birthday has already passed, and if so, we will be adding 1 year to their age, if not, we don’t add a year: + ( DAYOFYEAR( now() ) > DAYOFYEAR([birthdate]) )
Step 3 – We are selecting the birthdays from the relevant table in the db, and with each record, doing the calculation and taking an average, i.e. the avg () portion

And that’s it!

I don’t remember offhand the syntax if you were doing this in another db, such as MS SQLServer or Postgres, but the syntax should be very similar (or exactly the same, just depending on whether those functions operate exactly the same in those dbs).

So today we get an email from them soliciting feedback to their SimpleDB service, which we recently tried out for a few days, but found somewhat lacking for our needs. The email goes like this:

Dear OleOle,
Amazon Web Services is constantly striving to improve our customers’ experience using our products. We particularly want feedback from our new users.
On 6/23/2009, you signed up for Amazon SimpleDB. Please share your experience about getting started with Amazon Web Services by completing the following survey (9 questions): Amazon SimpleDB Getting Started Survey [This last bit being a link to their survey]. etc etc.

So “Great!”, thinks me, they are being proactive, and hopefully they will improve this service and make it useful for us. Alas, not so fast. The link to their “survey” goes to “Cannot Find Server” – basically that domain for the survey doesn’t resolve in DNS.

Maybe they should have created the sub-domain first?

That’s just so sloppy. Incompetent even. Is Amazon getting too big for it’s britches?