Ruby and Gentoo

[sweatje]

Are there other folks here using Gentoo and Ruby?

In reading about Ruby performance, it sounded like going for FastCGI was the best option for performance. I have tried following a few resources like this, but stumbled at the first steps. The eruby ebuild seems to fail on all systems I try to build it on.

Has anyone else had any luck getting this configuration running?

[McGruff]

Yes. So far all I've managed is hello world though

I wish there were more hours in the day...

[sweatje]

I have Rails running through webbrick, just not FastCGI. I know the applications I would roll out initially would have no noticable performance requirement either way, but I just wanted to do it right for the sake of doing it right

[platinum]

Yeah I installed it just as per normal (not using fcgi) - but it took a bit of messing around to get working.

Easiest way I've found is just

~ # emerge ruby rubygems
~ # gem install rails 

and my config file in /etc/apache2/conf/modules.d/20_mod_ruby.conf needed everying uncommented.

[sweatje]

and my config file in /etc/apache2/conf/modules.d/20_mod_ruby.conf needed everying uncommented.

I performed the same emerges. Have it working if I run
# ruby scripts/server &

But I don't recall poking around in the mod_ruby.conf file, will have to look there.

Thanks.

[33degrees]

I recall reading that performance under fastcgi is much better than under mod_ruby, so that may be something to keep in mind...

[ezmobius1]

Check out my thread on installing the whole rails/gems/lighttpd/fastcgi/php stack. I've used it to do over 20 rails installs and I am running production sites with the setup.

[platinum]

Here's the link if anyone's looking for it and is lazy

http://www.sitepoint.com/forums/showthread.php?t=301842

[sweatje]

Revisiting these issues, I think some of my problems stem from using ruby-1.8.3 pre release packages. All of the 1.8.3 versions seem to have some problems working and playing with other packages (rails code, eruby, etc). Forcing back down to the latest 1.8.2 release seems to have eased some of my intergration headaches.

HTH

[ezmobius1]

Yes ruby 1.8.3 has made changes to the std Logger class. There is a fix in edge rails but not in the stable version. So it is recommended to use 1.8.2 until the next stable release of rails. Which is rapidly approaching 1.0 ;-)

[paulfern]

Hello,

I tried:

emerge rails

and all the dependencies came in from there. Ruby 1.8.3, etc.

All of the apache configs the various docs ask for were already there in my current setup. But I'm still getting weirdness and 403 errors, even after aliasing the directory, etc.

It works great from the command line, but my goal is to have it working from Port 80.

???

[sweatje]

You can see I had problems with Ruby-1.8.3, you might have better luck doing

emerge =dev-lang/ruby-1.8.2-r2

to change the port, just edit the port number to 80 in the scripts/server on the
:port => 3000,
line.

[Radley]

You can see I had problems with Ruby-1.8.3, you might have better luck doing

emerge =dev-lang/ruby-1.8.2-r2

to change the port, just edit the port number to 80 in the scripts/server on the
ort => 3000,
line.

You can also do `script/server -p 80` if you just want to switch the port temporarily.

[MiiJaySung]

From experience, I wold say that you will get better performance from using native C MySQL bindings than the Ruby based ones, than switching webserver. I guess this to some degree depends on your applications use of the database, and what mode you are using (development mode uses a lot of reflective SQL to get table info). However I don't know if that applies to you being an Oracle user. Maybe you have similar C bindings about for Oracle.

I would stay clear from Apache. You'll probably have little luck with Apache 2.x being stable. I think 1.x isn't too bad though. Unless you have stuff that specificly uses Apache, move to lightty. If you need both, you are better running the main / most used webserver on port 80, and using another port for the other server, and then using the proxy module in one of the webservers to pipe requests through. Can't say it's a very elegant solution, but it's better than running Ruby on Apache.