From: Lothar Scholz Date: 2004-04-27T14:28:41+09:00 Subject: Re: How do I scale large Ruby web applications? Hello Dan, Tuesday, April 27, 2004, 7:19:44 AM, you wrote: DJ> 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! >> >> DJ> Distributing objects is one thing, but using drb as a request/response DJ> and control protocol is what I am considering at the moment. I was DJ> thinking of FCGI, but it is all or nothing in the sense that it forces DJ> the whole hit service out of Apache. But a considerable amount of cgi DJ> processing is not session dependent and is more appropriate in the DJ> Apache side (I use mod_ruby). Separating non-web application logic from DJ> cgi/web processing is one way to efficiently distribute the load. Does apache never use threading inside one of the preforked apache processes ? I thought 2.0 is doing this by default, even on Unix. And you should measure if enabling threading reduces the overhead more then FCGI is adding. By the way if you have your own webserver (so you don't need all the flexible configuration features of apache) then you should never use apache if performance is important. Apache is not a very fast webserver. A lot of other servers give you twice the responds then apache (or even more if apache is not configured correctly). -- Best regards, Lothar mailto:mailinglists@scriptolutions.com