Category Archives: engineyard

Feb 20 2009
3 Comments
engineyard, NWRUG, Programming, Rails, Ruby, Tech, Uncategorized, Web

NWRUG February 2009 – Nanite talk

For the first time in quite a while we had a talk at NWRUG, it seemed to go well and the free Pizzas and Beer provided by Engine Yard were very popular. About 12 people turned up. I was the only speaker and did a 45 minute talk on Nanite with a brief introduction to cloud-computing as that’s the environment I see Nanite being most useful.

Thanks to everyone who turned up and Engine Yard for the sponsorship. I promised a blog post with links to some of the resources from the talk, and here it is!

Useful links from the talk

Nanite (of course)

Kestrel (a starling replacement)

Delayed Job

Warren (A wrapper around AMQP from brightbox)

Engine Yard Solo

As I mentioned in the talk you can probably get away with using third-party APIs and calling it ‘cloud-computing’, this set of slides is really interesting:

Web Hooks and the Programmable World of Tomorrow

Lastly the slides on SlideShare, though they don’t make as much sense as they do with the talk & my notes.

*update*

Pastie: control rabbitMQ using Nanite, controlling god using Nanite.

Next Month

More talks! Asa Calow has agreed to do a talk on Solr and I rather foolishley agreed to do another talk on Sphinx.

Tagged , , , , ,
Feb 08 2009
4 Comments
engineyard, overcycle, Rails, Ruby, Web

Whoooooosh – the Recycling Group Finder gets faster

This afternoon I implemented a CDN (Content Distribution Network)  for the Recycling Group Finder, it only took about an hour and has slashed page load times on the site.

Whilst working for Engine Yard today (yes, on a Saturday!) we got a ticket in asking for CDN recommendations. This got me thinking about the recently announced Amazon Cloudfront CDN, specifically how cool it would be to use it for the Recycling Group Finder (a personal project). It’s an internationally targeted site and would benefit from the faster page load times a CDN will bring.

Why Cloudfront?

Cloudfront is built on Amazon S3, a well-used and trusted technology and many of Engine Yard’s customers are already using it. The chances are if you’re already using S3 for storing assets Cloudfront will be dead-simple to get running. I wasn’t, though it didn’t take much extra effort.

It’s easy…

Really easy. There’s a really useful tutorial up that gets you most of the way there, the Firefox S3 plugin is amazing. All that was needed after that was a single line change to my environment.rb file in my RubyonRails project:

and my javascript and CSS files were being served super-fast from the Cloudfront CDN. Sweet! It took a bit more work (and a custom helper) to get some of the other assets served, but not much.

Very. Very. Fast.

The speedup is significant. The site seems snappier when visiting in a browser but I also ran some before and after speed tests using the Pingdom tools page. The results were impressive. The homepage went from a 16.1 second load time (including all assets) to 1.1 seconds:

Before (16.1 seconds):

Homepage for Recycling Group Finder served from server

After (1.1 seconds):

Homepage for Recycling Group Finder served from Cloudfront

The homepage saw the most impressive speed boost, but sub-page load times improved significantly too. This is the before and after tests for the San Francisco Freecycle page:

Before (5.6 seconds):

Recycling Group Finder sub-page served by the server

After (1.6 seconds):

Recycling Group Finder sub-page served by the Cloudfront CDN

Worth the effort

Hell yeah! It took a really short amount of time to get running (helped by RubyonRails built in support for asset hosts) and the site flies. Give it a go!

Tagged
Jan 13 2009
1 Comment
engineyard, Programming, sysadmin, Tech

Connecting to your Engine Yard MySQL database using SSH tunneling

Quite a few people want to access their Engine Yard hosted MySQL databases remotely which is fine, just complicated by the fact that the database slices are only accessible from the slices themselves. There is no remote access available by default.

Lee Jensen posted a useful forum post Accessing your DB externally, but this advice doesn’t work so well for windows users so here is a brief tutorial.

First, download putty if you haven’t got it already, open it up and configure an SSH connection with the IP address and SSH port of your slice. You can get these from the welcome email you were sent:

Next, go to the Connection -> SSH -> Tunnels config section and configure as following:

In this example I have used mysql50-staging-1 as the MySQL server hostname, replace this with the one you are trying to access. When you have entered the source port and destination click ‘Add’, then ‘Open’. You should see a screen like this:

Enter the slice login details (not the MySQL login details!) and you should see a standard login prompt:

Right, that’s the last of putty for now. Open up your MySQL GUI (I am using MySQL Administrator in this example) and configure it like so:

Make sure you have specified localhost as the mysql hostname, that you are using the MySQL database login credentials and that the port matches the local port you set up in Putty, in this case 13306. Click connect and you should see something like this:

Success!

You should be able to change these instructions for any MySQL GUI (the putty config will remain the same).

Jun 10 2008
7 Comments
engineyard, Programming, Rails, Web

Flushing memcached servers the easy way

This is easy right?  Can’t you just restart the memcached server? Well yes, but you may cause errors in applications that are already connected to it. You can follow your memcached restart with an application restart, eg for a Ruby on Rails app:

# /etc/init.d/memcached restart && mongrel_rails cluster::restart

Of course if you have more than one application server you have to restart your app on every single one. This would work on an engineyard slice assuming you have the eycap gem installed:

$ cap production memcached:restart
$ cap production mongrel:restart

Restarting your application is not ideal however, you will lose anything cached in memory, cause delays to users trying to access your site, that sort of thing.

So what can be done? The answer is really simple. Assuming a memcached running on the local machine on the default port:

$ echo ”flush_all” | nc localhost 11211

Easy!

Follow

Get every new post delivered to your Inbox.