From: kwatch@... (kwatch) Date: 2003-09-10T22:48:35+09:00 Subject: Re: WEBrick and mod_ruby performance You can try 'esehttpd' http://ghost.math.sci.hokudai.ac.jp/esehttpd/en/index.html It is very fast as HTTP server and CGI engine, twice (or more) as fast as Apache + mod_ruby. -- regards kwatch quixoticsycophant@yahoo.com (Jeff Mitchell) wrote in message news:... > I've been scoping out ruby for an upcoming server project. > > For my purpose, performance will be a factor because the server will > be slending data in real-time much like a multipayer game server such > as Quake (as opposed to waiting for user input). Quake is an extreme > example, though -- it wouldn't be nearly that demanding. > > I am very impressed with WEBrick, and this would be my primary choice > were it not for performance concerns. > > How does WEBrick scale? Looking through the code, it appears that new > requests are handled by a ruby Thread -- as opposed to a native thread > or a fork. What happens with 40 threads, all transferring data and > doing stuff, all being handled by a single ruby process setjmp-ing and > longjmp-ing around? I'm guessing performance would be poor. > > Next option is mod_ruby. Now I don't even understand how mod_ruby > works with Apache 2.0 since the ruby interpreter isn't thread-safe. > So that's all a mystery to me. Apache 1.3 + mod_perl is probably > well-tested and perhaps the most appropriate choice. > > Are the above assumptions correct, and are there other options? One > more option which comes to mind is to simply write a forking ruby > server from scratch. This would mean more development time, but how > much more I'm not sure.