Using Ruby’s timout to keep the user experience snappy
Wednesday, October 25th, 2006On a my Ruby on Rails based San Francisco Sailing Weather website I make calls out to flickr.rb to retrieve photos.
(more…)
On a my Ruby on Rails based San Francisco Sailing Weather website I make calls out to flickr.rb to retrieve photos.
(more…)
At GreatSchools we’ve had 3rd party ad server outages or slowness effectively make our site unusable as users browsers waited for certain ads to render before rendering the rest of the page. I had originally thought just specifying height and width of the div element around the ad would be enough for the browser to move on given a slow ad load but in my tests with various ad servers that turned out not to be the case. After some research I discovered that the trick that some sites (such as Digg.com) employ is called source ordered content where you put the content in the order you’d really like it in (be it for SEO or for deferring ad calls) and then using CSS or Javascript to move it to the proper place.
(more…)
At GreatSchools we do around 1M real page views per day and another 250k or so for crawlers. Before content compression we were running well in excess of 10Mbit/s during peak hours and were getting hit with bursting charges on high traffic months. When we switched our proxy servers to Apache with mod_deflate (gzip based compression) we saw a 35% decrease in bandwidth utilization and the 3 proxy servers that do the compression and sit in front of our 10 web servers barely register a load at all.
(more…)
I’m amazed by how often DHH can keep coming up with newer, simpler, and more elegant approaches to web development that really make you think. In his recent blog entry/keynote he discusses using HTTP’s PUT and DELETE methods to more elegantly model CRUD operations (slides of his presentation are here) and this is a good 3rd party summary of his keynote:
So rather than the old school approach of:
(more…)
Update: Bryce pointed out a servlet filter you can implement to disable JSESSIONID’s… very nice!
When we started moving GreatSchools from Perl to Java + SpringMVC + Hibernate one of the first things we had to figure out was how to disable jsessionid’s from getting appended to URL’s when using c:url in a JSP page. Jsessionid is terrible for search engine optimization because crawlers that don’t have cookies enabled will get URL’s from your pages with a jsessionid parameter appended. This makes it virtually impossible for a crawler to match the URL from an inbound link to your site with a page it has already crawled. What’s worse is that you risk having your page rank hurt with Google because it thinks you’re serving duplicate content, ouch!
(more…)
This tongue in cheek post by Dion about Ruby not scaling made me chuckle but also got me thinking!
The whole question of whether a modern language scales or not is really the wrong question to ask. Almost any language will scale horizontally. Here’s one anecdote as an example: when we were going through the language selection process at GreatSchools several years back we rewrote some key pages in PHP, Java, and Perl (mod_perl) to try them out. Not surprisingly (more…)
After upgrading Lighttpd to 1.4.11 from 1.4.8 it was no longer working with my Ruby on Rails project saying it couldn’t find public/dispatch.fcgi. Well, it turns out they made this security fix which breaks relative paths typically used in lighttpd.conf: (more…)
Keeping current with SEO has always been a challenge for me, it reminds me of paying bills, you have to do it but you don’t always want to. However, as the majority of our traffic comes from search, staying on top of it is important and as a result we’ve seen massive traffic growth (more…)
Eric Hodel posted their production website server setup over at the Robot Coop that handled 2.5M page views in a day not too long ago. I love this kind of information because it helps me get a feel for how we’re doing. At GreatSchools we serve around 900,000-980,000 page views on an average weekday, our record day was a bit above 3M page views, and siege load testing puts our cap around 4400 page views per minute.
The great thing about using siege is that we extract the load test from our access logs so that we can simulate real conditions. We size the hardware based on running at around 25% of our capacity on an average weekday which usually gives us just enough breathing room to handle a front page feature on Yahoo or AOL when those happen. (more…)