Archive for the ‘performance’ Category

Twitter flies off the rails

Thursday, May 1st, 2008

According to noted internet pundit Arrington twitter has made the call to rewrite and move off ruby on rails. Not really a shock, rails is fundamentally not going to scale up past a certain point.

The uncharitable part of me (and the part that is confident nobody reads this blog) thinks that the vast majority of rails developers have never been around the kind of scale we’re talking about when we say rails doesn’t scale. Especially when I see something like this:
Image from a slide show: Scaling rails is easy

I love that items 2, 4 and 5 are REALLY REALLY hard.

More likely though those developers haven’t faced an app that is particularly hard to scale. I think the issue is less “does my framework scale” and more “is my application going to be hard to scale”.

Twitter is a great example of the kind of app that is very hard to scale, regardless of the platform. Rails is probably not the culprit here, but I doubt it is helping at all. In fact, at this point I would suspect twitter will do what everyone ends up doing when this happens: php frontend talking to a web service driven by java (or c). Because it turns out when the problems get real hard you don’t want a scripting language to handle them.

Rails isn’t bad, but it is isn’t “easy” to scale, except in cases where the application is easy to scale (content). Rails is designed by small, custom app developers for small developers. It provides one major benefit: it makes it faster to develop a certain class of applications. Thats it. So if time is money (you are a small dev shop) rails will make you money. Otherwise rails give you very little. I don’t think it would be a bad choice for most apps, but I don’t think its the panacea many rails advocates would claim.

Sloooow

Friday, December 21st, 2007

Performance on this blog sucks. Right now I am caching the home page to disk, which is quite fast. I got really ambitious and was planning on using apc user cache to keep the homepage in memory, but dreamhost makes me run my custom compiled php as fastcgi…which means no shared memory space and no apc user cache.

Oh well, at least the disk cache homepage is nice. For the tiny amount of traffic I get disk cache should do the job. Cache refresh is really hacky, and comment posting remains slow. (also the stylesheet is busted for the comments page…) But I have a day job…