Just checked out this video (links directly to m4v file) that someone forwarded to me earlier today.

Basically when trying to scale a rails app (or really any web based app) there are three core rules to live by.

1) Spindles = Bad. Talking to databases and/or file systems are slow.

2) Dynamic to static. Dynamic content is your enemy.

3) Push to the edge. Push everything as close to the client as you can.

"Rails scales exactly like any other web application... You need to take into account all the components, from the moment the request is received into the load balancer, all the way down, and all the way back again."

We're constantly working on improving performance on Fan Profiles as it continues to grow and have learned that these core rules are indeed the way to live by when working on scaling issues. Our work is far from done and likely will never be, but it's cool to see another sucessful rails team discuss these issues and how they tackled them.

If you read my previous post on YSlow!, you know we made every attempt to assuage the YSlow! gods appeasing their insatiable appetite for efficiency.

So, we configured our S3 buckets to serve gzipped CSS and JS.

Unfortunately, we didn't account for how horrible the IE browsers are.

We began getting emails from folks in our Bristol offices with screen shots of pages that looked like the CSS hadn't loaded.

We booted up Parallels and had a look, and both IE6 and 7 looked fine to us. So we sent the usual replies: Try clearing your cache, it must be a setting you have on, upgrade your browser, etc, etc.

You see, we don't use PCs and we don't use the network, which just about everyone else in Disney uses. We have clean, unfettered, beautiful access to the Internet, so this problem seemed like it had to be bunk.

But then we started seeing user reports of the same thing. So I got my Google on and started researching gzipping assets and IE. There seemed to be some stuff related, but not a sliver bullet, and nothing that could explain why our IEs were fine and Bristol's weren't.

Then I remembered some of the pure wackiness that we endured on the network when I worked in Bristol. So we blew the dust of a Thinkpad Laptop, which was connected through our network, and brought up Fan Profiles on IE6.

Booyay! It was like National Turn CSS and Javascript Off For A Day, and we were failing miserably at it. Oh, Firefox and Safari and Opera were fine, but that's to be expected.

I didn't really know what to do because we had seen pretty serious page load gains from gzipping our content.

In the end, we decided at least temporarily, to not gzip, so we rolled back, and problem solved.

Interestingly, at the same time, our CNAME request for serving assets through Akamai completed. When I set up the configs for Akamai, I requested that it gzips the content.

So in theory, the content was being gzipped again. Even more interesting, IE on the network still looked fine.

YSlow! was happy. The network was happy. I was suspicious.

Was the content really being gzipped?

I looked around for a while to find out how I could test this. To save you time:

curl -I -v --compressed -A "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" http://a0.espn.go.com/javascripts_c/main.js?1210961500

And yes, it was being gzipped.

So for reasons I still don't understand, IE + corporate network + Gzipped content from S3 != E + corporate network + Gzipped content from Akamai, being sourced from S3.

Below you will see two YSlow! screen shots. One is good and one isn't.

I've been a huge fan of YSlow! and following its suggestions since it came out, but actually implementing these suggestions on a site the size of ESPN.com can be very difficult, especially since, until recently, ESPN.com has chosen flair over speed.

But with our opportunity to start over with Fan Profiles and Widget Center, we have made every effort to abide by the YSlow! way.

As you can see, we were just lower than an A, and we have one more change to roll out that should finally get us there, which is really exciting.

The hardest part is reducing dns look ups because there are so many different javascript files that are brought in through analytics, sponsored links and advertising that are beyond our control.

Any way, I'm proud of the team for sticking to this and making it a priority, and it has helped lower our page load times as well.