Showing posts with label Rails scaling. Show all posts
Showing posts with label Rails scaling. Show all posts

Friday, 13 June 2008

Why EngineYard?

We get frequent questions about our hosting strategy:

  • Why not host yourself?
  • Why host in the US?
  • What's so good about EngineYard?
Here's a really good interview with Tom (EY CTO) and Lance (EY CEO) discussing the answers to the questions above and more.

A good interview and a great indication as to why we work so closely with EngineYard.

Thursday, 29 May 2008

NewRelic

We recently signed up through EngineYard for the NewRelic beta programme. What a revelation!

We are no longer digging through log files for all the important (but hard to find) data on bottlenecks or benchmarking data. We now have a clear picture of normal and good application behaviour.

Some highlights:

  • easy install - minutes
  • real time data
  • responsive support
The last aspect is worthy of note - trying the developer mode on one of our apps caused a graceful failure - NewRelic didn't show up because of some gnarly routing in our app. I dropped the guys at NewRelic a quick email expecting a response in 24 hours (perfectly adequate IMHO). 10 Minutes later I had feedback and a resolution in a little while longer - awesome speed guys!

As we like to act on data, this app rules - now we have the data and can operate on our apps with greater precision than we thought possible.

I seriously recommend NewRelic if you want to know your Rails app inside and out.

Credit has to go to both partners in this venture - EngineYard has always delivered kick ass hosting and support for Moneyspyder and now EngineYard and NewRelic together help us deliver world class performing and scaling Rails applications to our clients.

Sunday, 20 January 2008

How was your '07 uptime?

Moneyspyder went live with our first clients in June last year. We have maintained our approach of gathering data with regards to client uptime using Site Confidence.

Having returned from my Winter Sun break I can now publish some findings from our data.

Our average uptime across all clients was 99.75% - this equates to 3.6 minutes per day on average of downtime. Our worst weekly uptime was 97.82% (best was obviously 100%!!)

Now, consider the reasons for outages here; typically a large Rails deployment will essentially take down a site for a short period of time. If we take out the periods where deployments were scheduled we see slightly different figures:

Average uptime soars to 99.91% - fractionally more than one minute per day of downtime (mostly scheduled infrastructure work) with a worst uptime of 99.42%.

As you will have seen on our website we gather data, schedule updates and roll out changes based on data on a monthly rolling cycle. Thus, identifying deployments is easy and not just because we maintain deployment audit trails. Business forecasting and scheduling gets easier with the monthly cycle. All those large marketing campaigns leading up to busy periods are 100% safe - any downtime is worked around the main retail peaks including a change freeze if necessary and certainly scheduled out of hours otherwise.

What of the other outages? We've seen a mixture of:

  • scheduled infrastructure maintenance (scheduled outside of business hours)

  • post deployment issues requiring patches (something we strive to eliminate)

  • upstream connectivity issues (new pipes now in use)

  • load balancer outages (resolved by Engine Yard)

  • mongrels (software component) restarting due to memory leakage (also resolved through new deployment process)



So, I think we have a good basis to build on in terms of reliability. '08 is looking pretty neat already - nearly at the end of Jan and so far we are exceeding last years averages (99.97%).