Ruby on Rails Development
September 30, 2005
I was having a conversation with Eric Molitor (a Dallas programmer who is into Battlebots) today and we were talking about development in Rails. I explained how our IT services company hired a programmer to redevelop the help desk and trouble ticket system in PHP. The process took almost six months and the resulting product worked, but was too heavy (three months later and we have not launched the new system).
I then explained that one of our managers overheard our conversations about Rails and Ajax and decided to read a book on the subject. Eariler this week he took the help desk and trouble ticket specification and wrote a fully functional application in Ruby on Rails with a few touches of Ajax. Imagine a framework that can be learned overnight and allow smart programmers to develop great applications very quickly? Want to guess why everyone is so excited?
So what is so great about Rails? Basically, it is easy to rapidly prototype and launch an application. We were able to see what worked and what did not work. Eric agreed, but explained that Rails has scaling issues. I assume he is correct on this point; however, by the time scaling becomes an issue you likely will have the time and resources to resolve the issue. Why spend time and money creating very scalable applications that may never see the light of day. Get them up and running now…

Local
September 30th, 2005 at 4:06 pm
Congratulations on delivering valuable software quickly!
Please do share any scalability concerns that you might have. We haven’t met them yet, so a heads up would be nice.
Currently, we have applications like 43things/places/people that are pushing 1M+ web requests per day across 3 machines. Basecamp is serving hundreds of thousands of users, too.
All because we follow the basic model of Shared Nothing. The same kind of architecture employed by most users of the LAMP stack. You know, like Yahoo and others that do billions of page views (yes, B) on similar approaches.
Anyway, once again congrats and may you continue to deliver.
September 30th, 2005 at 4:33 pm
Excellent post. I checked my feedreader while watching David’s 2 hour video entitled “Ruby on Rails to Basecamp” and you guys are blogging about it. Fantastic! I plan on spending the weekend learning as much as possible about the framework. I have many ideas that I want to ‘deliver’ but run into roadblocks attempting to implement my vision using apps built for other solutions.
September 30th, 2005 at 5:18 pm
We have just hired a new young developer, albeit with a decent amount of php experience, and are trying to get him on track (pun intended) with RoR. Once he figured out the conventions of the RoR framework, he was getting upto speed.
I am convinced that within a couple of months, a lot of his early code will be scrapped and replaced by more compact, cleaner code as a result of his increasing experience.
IMO, that’s also one of the strong points of RoR: its small LOC allows you to refine or completely replace code without feeling guilty…
October 1st, 2005 at 11:40 am
The two areas that I ran into issues were related to overhead in webbrick and FastCGI. Also had some issue with DB connection performance. From my side of the world there needs to be an exploration of the performance advantages and disadvantages of ROR if for nothing else to address them.
October 1st, 2005 at 5:06 pm
WEBrick and FastCGI are very different beasts. The former is primarily used during development as an easy way to get started without dependencies. The latter is what powers tons of big sites pushing millions of page views per day (but it has dependencies and is harder to setup).
What where the DB connection issues you had? Please do share, we’re eager to fix any mishaps.
October 2nd, 2005 at 8:46 am
[...]
October 2nd, 2005
Rails Comment Round Up!
In my previous post on Development in Ruby on Rails I received a number of intere [...]
October 2nd, 2005 at 1:50 pm
SCGI seems to make things easier than FCGI but on the DB side I’ll post some info in the next week or two. I want to ensure that what I saw was not specific to MySQL and SQL Server 2000 or my test environment.
The issue was the ammount of time spent fetching records from the DB. What was interesting was the time it took to fetch 1, 100, 1000, and 10,000 records was relatively close. It may just be that the overhead of getting a DB connection in Ruby is higher than what I’m used to seeing in an APP Server.
I have a colleague whom load tested a few prototypes on much larger hardware than I have access to at home. His issue related to scaling accross multiple cpu’s with Apache +FCGI +ROR. There are too many variables and uncertainties with his test to draw too broad of a conclusion. However its not the first time I’ve heard of such concerns when runnin on large SMP hardware. But as you said the share nothing approach should lead to near linear scalability and it may just be a factor of Apache/Ruby tuning on larger hardware.
I dont have access to anything larger than a two way box so its hard for me to reproduce his tests. However on the limited hardware I have I’ve started running test of my own. The biggest thing I’m seeing sp far is the impact of sub-templates vs templates. But I’ll wait to post numbers I’m comfortable with.
Even with all of that said, right out of the box Apache +FCGI +ROR had numbers that were “Fast Enough”. But “Fast Enough” is always relative. (To be honest I’m more concerned about hundreds of db hits a minute vs millions of hits a day.)