We’ve been on mod_rails for nearly a week and I’ve been noticing a couple of strange problems.

First, every once and while I’d hit a page and it would come up blank. Second, looking at google’s sitemaps status page told me that certain pages were getting a connection refused error. Also, I noticed the number of requests per minute from Google had dropped. (We use gl_tail for real-time monitoring of our apache logs.)

Then I started thinking that maybe the application instances are taking too long to spin up? I hit one of our staging services which was not active under mod_rails and I got a blank page . So I started combing the user documentation looking for something to set the minimum number of instances. (A quick google and I found that others have made similar requests.)

So then I discovered you can control when mod_rails chooses to shutdown idle instances using RailPoolIdleTime. We had were using the default of 120 seconds. It recommends you set the Idle time to 2 x average number of seconds a user spends on a page. With a little bit of playing around we set it to 600 seconds and found that to work best.

The results were almost instanteous, it took about 15 minutes before Google started crawling at the normal rate.

Mod_rails has been really easy to use so far. We’ve been happy with the performance (now that we’ve got some of the glitches out of the system) and we’re still hanging out for rubyentreprise.

We’ve been working on improving our YSlow ranking on ZoomIn Homepage. We scored 83 during the homepage audit 3 weeks ago, now we’ve managed to get it to 86.

To improve our YSlow ranking we been focusing on two things. First, we’ve been minifying our javascript & css. Second we’ve been improving our caching of javascript & css. (Which weren’t caching properly due to versioning problems)

From our optimisations, we’ve managed to shave an additional 9K from our javascript and css. It seems that our optimisation of whitespace etc wasn’t quite upto scratch! We’ve started using the excellent yui compressor to help with the optimisation of the files. We’ve also adopted a more formal asset control of our javascript / css using the rails plugin asset packager. It’s a great plugin to properly manage versions of our javascript etc. Now we can increase the Expiry tags for our CSS and Javascript way out, to maximise the cachability of our pages.

The next stage of our optimisation is to tune the number of images via the introduction of CSS sprites.

We switched ZoomIn from Apache + mongrel stack to mod_rails on the weekend. The transitition was a breeze. The configuration for mod_rails is super easy !

We’ve noticed the webserver is chewing through a lot less memory on the server and it scales up as demand grows.

Hanging out for ruby enterprise edition !

I had an interesting chat with Jason Roks over the weekend, who was here for the Xmedia labs.

He made this comment that stuck with me.

The only people who benefit financially from torrenting is the telecom’s companies.

ie. The content provider doesn’t get anything from torrents, only the comms companies get money for usage of bandwidth.

It makes you think…

When you have ‘cost per Gb’ charging system, its hard for companies to make money for offering downloadable content.

Nat Torkington posted about this presentation by Cloudfour on their research of the mobile web - Going fast on the Mobile Web. It contains some fantastic insights of how iPhone is changing the way that people are using the mobile web.



It also outlines their research into how mobile browsers deal with compression and caching. And details 8 tips on how to deliver content on the mobile web.

And tips for the iPhone.

When you partner that with Steve Sounders research on iPhone caching.

The iPhone cache experiment suggests an additional performance rule specific for developing web sites for the iPhone:

Reduce the size of each component to 25 Kbytes or less for optimal caching behavior.

Given that the wireless network speed on iPhone is limited and the browser cache is cleared across power cycle, it is even more important to make fewer HTTP requests to achieve good performance than in the desktop world…

Also, the maximum cache limit of all components is 475 - 500 KB. Minify all the JavaScript, CSS and HTML.

The future of the mobile internet is small webpages.

Finally, here is the slide deck, its well worth a read.

| View | Upload your own

Om Malik has just wrote a post about broadband usage in London. In London there are a numer of providers and they have quality services for WI-FI, Broadband and 3G. Here’s the full report from Ofcom .

In London:

* 40 percent of people watch TV or video content online.
* 20 percent make VoIP calls.
* 32 percent are using their mobile phones to access the Internet.
* 19 percent listen to audio content on their mobiles.

The evidence is mounting better broadband and mobile services will result in more usage and more opportunities for companies / content providers to create new revenue streams. Let’s hope things will change for the better this decade!

Google has just released the AJAX Libraries API. Google has created an API that allows developers to access a number of popular javascript API from the Google Cloud.

You can use the Google AJAX Libraries API to reference:

• Prototype
• JQuery
• MooTools
• Scriptalous
• Dojo

Why is this good idea ?

1. Its Fast - its hosted on the Google CDN.
2. The libraries have already been optomised ie. minified, delivered via compression
3. It enables better caching of key libraries from one site to another. ie. Visit site A that uses mootools it downloads the javascript. Visit site b that uses mootools and it fetches it from the cache.

How do I use it ?

Its really easy to use. Either call the scripts directly eg.

<script src=“http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js”></script>

or use the Google API to load them scripts.

<script src=“http://www.google.com/jsapi”></script>

<script>

// Load jQuery

google.load(”jquery”, “1″);

A couple of requests to Google

The AJAX Library API is a fantastic idea, but it could be better. We have a couple of requests .

1. can you host more of the legacy versions of the libraries. (We use an old version of prototype. The recent versions are a little bloat for what we need).
2. It would great if you could provide stats on how many sites in a particular country are using the libraries. Then we can see if there are other sites in that are using the same libraries and then we get the benefit of caching
3. Properly minify the scripts! Thanks for to Eric for pointing it out.
4. Fix the Website. The FAQ and Groups links are going to the wrong place !