Gregory Seidman
11/10/2006 3:24:00 PM
On Fri, Nov 10, 2006 at 08:50:12PM +0900, Leslie Viljoen wrote:
} I have the deciding vote in a new (rather large) web app we need to
} develop. I am experienced in Rails, but the other 2 guys on the team
} know only C# and very basic Ruby. About 25% of the app could benefit
} from existing classes written in C#.
}
} So I could force everyone to learn ROR, which they may or may not
} thank me for, or I could learn ASP.NET. I know C# well but have never
} used ASP.NET.
}
} I doubt execution speed would be a factor, since the bottleneck will
} be in the database and there would be very few concurrent users. We'd
} make a lot of use of Ajax.
}
} So is there any advice? Anything I should take into account? Has
} anyone done large projects in both environments?
I have worked on large projects in both. As a language, I enjoy Ruby more
than C# by a significant but not huge margin. As a framework, I enjoy Rails
more than ASP.NET by a large margin. C# and ASP.NET make it slightly easier
to have many engineers working concurrently, but not by a whole lot. Where
it really gets interesting is in deployment. I am going to paint this in
rough brushstrokes, and make some generalizations, but I hope the
high-level view will be of use in making your decision. I'm also going to
use numbers without units, which are really only useful for relative
comparisons since they mostly represent a vague performance metric having
something to do with incoming requests based on my experience.
A single box running IIS/ASP.NET can probably manage at least 20-30. More
than that and you need more boxes and a load balancer, plus you need to
make sure that all of your shared state is in the DB (or another explicitly
shared resource) rather than ASP.NET's various implicitly shared resources
(e.g. class variables). You also have to figure out how to make sessions an
explicitly shared resource (it might be easy, but it's been a while and I
don't remember). It scales roughly linearly that way for a while, probably
to 500 or so, then gets much as when the shared resources become a
bottleneck.
A single box running a single Rails process (whether lighttpd or mongrel)
can manage maybe 5-15, depending on the demands of serving particular
requests. Beyond that you need at least multiple Rails processes and a load
balancer, with session data stored somewhere other than in-process memory
(memcached is a good choice). A decently powerful box with plenty of memory
should be able to manage enough Rails processes to support maybe 40-60.
After that, it scales roughly linearly as you add boxes and processors, up
to maybe 1000-1200. From there it gets significantly messier because you
need to deal with multiple levels of caching granularity, plus the same
concerns about shared resources as ASP.NET.
It sounds like your intended application will work well under either, given
your small team and expected deployment size. The main
tradeoffs I see for your app are the existing code and that while Atlas
makes AJAX stuff easier with ASP.NET if you have anything trickier than
what Atlas supports you will find it more difficult to deal with in ASP.NET
that you would in Ruby.
} Les
--Greg