rc3.org Rafe Colburn on software development (and other topics)

My 2c: Outsourcing comments to services that know what they’re doing wrt scaling takes care of that. Then (at least with Disqus) you just need static JavaScript to inject the comments into your page.

Posted by Chris Winters on 18 March 2011 @ 5pm

Or you can always include little bits of dynamic content using SSI, but keep the bulk of your website static. If even that becomes untenable under huge load, simply switch of server-side includes and you still have a functioning website.

Posted by Stijn Debrouwere on 19 March 2011 @ 10am

I wouldn’t use SSI, but you could use AJAX comments or an IFRAME for the dynamic bits.

IIS has built-in page caching even for dynamic pages, with configurable TTLs etc.

An in-memory cache of most of the most-hit pages on a blog wouldn’t stretch any modern machine, and sending results right out of a string in memory is about as fast as it’s going to get.

The resilience argument is a good one although that’s more a question of “Why aren’t databases as robust as DNS or Apache?”

Posted by Jacob Davies on 19 March 2011 @ 11am

The trouble with AJAX/iframe is that you don’t know if search engines will pick up on it. Though I guess some people’d consider that a feature rather than a problem, and don’t care about indexing comments too.

Posted by Stijn Debrouwere on 19 March 2011 @ 12pm

I could say that for small sites, it doesn’t matter, but for big sites, baking is essential.

I work for a company whose site gets on the order of 2-3 million unique visitors/month. We regularly get Drudged, Slashdotted, Farked, Digged, Tumbl’d, etc., etc., etc. and it rarely causes disruption.

Baking our pages is the main thing that allows us to serve a heckofalot of content with limited (i.e., non-infinite) resources. We regularly update pages without issue, as our CMS takes care of rebaking everything that changes.

I had a chance to meet with Matt Mullenweg (the guy who invented WordPress) a few months ago and ask him about performance, etc. for WP. His suggestion was to have one master MySQL that handled writes + several slaves that handled reads. He also suggested throwing a bunch of commodity (i.e., cheap) app servers into a cluster. He actually said he didn’t like Supercache as it caused problems with concurrency.

It has been my experience that Movable Type is superior to WordPress if there’s a heavy load and one has limited horsepower. MT lost the war for non-technical reasons (6-apart basically dropped the ball: http://www.majordojo.com/2011/02/how-did-wordpress-win.php).

Posted by Bryan on 19 March 2011 @ 3pm

Just to be clear, Matt Mullenweg did not “invent” WordPress. He forked WordPress from a product called b2/cafelog. WordPress today is very different from the original version, and Matt gets credit for making it the success that it is.

The same can be said for MovableType. Ben Trott created MovableType but you can see a lot of the influence of a early blog solution called GreyMatter from a developer named Noah Grey in it.

Posted by Cameron Barrett on 21 March 2011 @ 11am

Movable Type (even the original) and GreyMatter were two very, very different beasts. I don’t remember how alike they were in terms of user interface, but in terms of how they were written, they were not alike at all.

Posted by Rafe on 21 March 2011 @ 11am

Yes, I agree. They were different but I clearly saw the influence of GreyMatter within MT. I wish I had my old GreyMatter install so I could refresh my memory of how it worked. All I have is the HTML output as archived by archive.org for a site I built in GM back in 2001.

Posted by Cameron Barrett on 21 March 2011 @ 2pm

Cam, I might still have a GM deployment stashed somewhere — if I find it, I’ll send you a copy. (I don’t remember what it looked like, but I switched to MT circa MT3, so I wouldn’t be able to compare it to early MT designs either.)

Posted by Snarkout on 21 March 2011 @ 6pm

Thanks for the history lesson!

Posted by Bryan on 23 March 2011 @ 1am