From: Nick Van Weerdenburg <nick@...>
Date: 2004-04-28T05:47:32+09:00
Subject: Re: How do I scale large Ruby web applications?

This is very common is J2EE architectures with the Apache/Tomcat web 
app tier, and the EJB Container business logic tier. While RMI has some 
cost, it's less then expected, especially in the context of the 
business logic being the main factor for scalability. That said, a 
poorly designed webapp->businesslogic interface would generate too much 
RMI chatter and cause issues. However, a high-level cohesive high-level 
business transaction interface to the business logic tier makes RMI 
very workable, and it's also good design. And now that the business 
logic is out-of-process and you have a lot of scalability/clustering 
options.

On Apr 27, 2004, at 1:19 AM, Dan Janowski wrote:

>
> On Apr 26, 2004, at 03:41, Sascha Ebach wrote:
>>
>> In my understanding the biggest problem in scaling Ruby (cpu wise) is 
>> that it doesn't have native thread support, yet. What this means in 
>> terms of a web application is that if you only have let's say 30 
>> concurrent users on a fairly new piece of Hardware this is not a 
>> problem. But what happens if your site suddenly gets very popular and 
>> you jump from 20 to 200 or even 2000 concurrent users? How do you 
>> scale such a web app? If you were to program this web app in Java or 
>> any other language which supports native threads you could simply 
>> throw more cpus and ram at it. I am thinking of a blade server here. 
>> The more users you get you simply stick another blade in your server 
>> and have your piece of mind. As I understand it you cannot do 
>> something like that with Ruby. Enter Distributed Ruby (DRb).
>>
>> As Martin Fowler states in his first law of distributed object 
>> design: Don't distribute your objects! 
>> <http://c2.com/cgi/wiki?FirstLawOfDistributedObjectDesign>
>>
>
> Distributing objects is one thing, but using drb as a request/response 
> and control protocol is what I am considering at the moment. I was 
> thinking of FCGI, but it is all or nothing in the sense that it forces 
> the whole hit service out of Apache. But a considerable amount of cgi 
> processing is not session dependent and is more appropriate in the 
> Apache side (I use mod_ruby). Separating non-web application logic 
> from cgi/web processing is one way to efficiently distribute the load.
>
> Dan
>
>