On 11/5/05, Bill Rawlinson <[EMAIL PROTECTED]> wrote: > I don't know about Arf! and I don't really know what your definition of a > large-scale high-traffic app is but I think Rails may suprise you with the > amount of traffic it's apps do seem to handle. Now, granted, the more > mainstream apps I have seen with Rails have been fairly trivial but they do > seem to support large amounts of traffic fairly well.
If your app behavior maps 1-to-1 onto your database, I expect it does OK. I meant scalability in two ways: (a) pure performance under increasing load (b) ability to handle increasingly complex requirements and enhancements. The big selling point for Rails (and Arf!) is how little code you need to write. That is, how little code you have to write to get a simple CRUD app up and running. If you have a legacy DB that doesn't match Rails' conventions, you end up writing quite a bit of mapping code. If you have complex relationships between entities in tables, you have to write a lot of 'wiring' between classes (and it's not clear to me from reading the Rails material and experimenting with it how far Rails' ability to represent relationships realistically extends). If you want fancy web forms, you have to write them yourself effectively from scratch. In other words, the benefits of Rails seem to diminish with the complexity and sophistication of your application. On the performance side, it's hard to tell how much Rails does at generate-time versus run-time in terms of supporting interaction with the database. That's why I wouldn't *expect* it to scale in terms of performance in general. Like I say, for 1-to-1 mappings, it may well be fine but, again, I remain suspicious of its scalability. Experience tells us that in order to scale an application we often have to apply caching and / or tune the SQL. Yet neither of those are exposed in Rails, limiting our ability to tune things. > 43things is the first that comes to mind (43things.com) - but it has a > userbase of 120,000+ that use it both via it's web-application and via RSS > syndication (RSS that is no doubt generated by the same Rails codebase as > the web-app). RSS doesn't really need to be very responsive and 120,000 users is not a very big number (how many are active concurrently?). I believe macromedia.com has between 10m and 20m registered users and gets around 40,000 concurrent sessions during morning peak traffic (five servers, each running two CFMX instances). If the users / peak sessions ratio was the same for 43things, that would mean around 300 concurrent sessions which is really negligible traffic. I'd hope that 43things handles all of that on a single server? (Even if you were to argue that only 2m mm.com users are 'active', that would still only map to about 2,400 concurrent sessions on 43things' user base which is about half the traffic one of our server instances handles during the morning peak) > I'm not sure it is widely used enough to have any real studies on it yet. Probably true. I don't want folks to think I'm being unnecessarily down on Rails. It definitely has something to offer and similar functionality in ColdFusion would be neat - and help a lot of people build relatively straightforward applications very, very quickly. There's definitely a benefit in that. And if such applications can support even 1000 concurrent sessions on a single server, that represents quite a user base. Saying something can't scale doesn't diminish the value of that something for a given set of usage scenarios. There are a *lot* of scenarios where scalability (in either form) is not actually very important. I would guess that the vast majority of us (CFers) build apps that actually don't need to scale - I know that most of the code I write does not need to scale. Sometimes it needs to scale in complexity only, sometimes it needs to scale in performance only, sometimes both, most times neither. -- Sean A Corfield -- http://corfield.org/ Got frameworks? "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
