The team from ActionThis have created a new product called Runtime Page Optimizer that will dynamically optimise your webpages at runtime. It looks like a fantastic product to solve a lot of the problems highlight by the NZ Homepage hall of shame.
Runtime Page Optimiser features:
Combines all javascript and css on the fly
Generates CSS sprites on the fly
No code modifications required!
Runs on ASP.net 2 and and IIS 6/7
Compatible with IE6/7 , Firefox 2/3, Safari 3
The product is currently in Beta and from the demos it already looking really great.
Well done guys, I look forward to seeing this product hit 1.0!
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.
