Main Area and Open Discussion > General Software Discussion

Linux webserver du jour?

<< < (3/5) > >>

f0dder:
Why is it that nothing on linux is ever easy or transparent? :)

So, ignoring httpd-specific modules, it seems that there's basically two ways of running ruby apps from a webserver: with a (fast)cgi process, or some ruby-specific httpd (which means the "main" httpd will basically run as a proxy for this backend).

When adding a Cherokee RoR vhost, it sets up a pool of three handlers ("sources"), each running on a separate port. Each is started as "/var/www/appname/script/server -p portnum". So far, so good - this isn't generated by default and I'm not sure just what to put there...

I've been looking around trying to figure which "glue" to use. So far it seems that Thin might be a good choice, but I'm really not sure. The whole ruby stack honestly confuses me, and there's apparently a lot of choices. A single Thin daemon, a cluster of mongrels, the (standard?) test-while-developing WEBrick, et cetera.

Tested the Thin thingy by simply doing a "thin start" in the rails app root folder, and it seems to work like a perfect drop-in replacement for the standard webrick, I can access the app on the default port 3000 - yay. Haven't set up the 'server' script properly yet, but have manually started a Thin instance running on the port defined in the Cherokee setup. Seems to work; there's some issues wrt. redirecting not-logged-in users (port number is stripped from URL, which it isn't when connecting directly to Thin), but apart from that stuff seems to work. Unfortunately, it seems like my desktop-client JSON calls still aren't gzip'ed, but at least the response headers show I'm getting data from Cherokee and not directly from Thin - so it should be possible to get gzip further down the road.

Might eventually end up with a nicely running system, but this is so darn typical of my experience with linux systems: poor documentation, outdated how-tos, and a lot of manual work for stuff that plainly ought to "just work". This bitching is directed towards the ruby/rails stuff, btw, Cherokee seems like a decent product.

JavaJones:
There's also Phusion Passenger, though if you're moving away from Apache and don't want to run Nginx it might not be of interest. The same people make "Ruby Enterprise Edition" that's supposed to reduce RoR memory usage 30% (but, I gather, only when used with Passenger). Interesting, I dunno.

The only reason I mention these is my Rails-specific host Rails Playground offers all these, and I figure they might know something about the subject. :D Their configurations are:
"Pre-configured Ruby on Rails with Apache/Passenger/MySQL, Mongrel/Nginx/MySQL, or Lighttpd + FastCGI Images Available"
which might give some suggestions on good cooperative system configs.

- Oshyan

f0dder:
Ok, so Cherokee is a nice product and I really like it's config section, but I ran into a bug that apparently hasn't been fixed yet. Short story: host is accessed via a SSH tunnel and /etc/hosts magic - so I connect to "http://myapp.local:4200" on my laptop, which is SSH tunneled to the test-server's own port 80. On HTTP 302 (redirect), the custom port is stripped from the Location response header, which means stuff obviously ends up not working.

Also, Cherokee's default setup of starting an appserver interpreter on demand means that the first time an instance is after server restart, you get a "502 bad gateway" HTTP error. This can be fixed with Cherokee by starting the appserver elsewhere, it's just the default way of doing things that is bad.

I'll check out nginx+passenger now - thanks for the suggestion, JavaJones. It's one of the combos I already saw mentioned elsewhere (and has just been recommended from yet another party), so I guess it's time to give it a try. I'll keep you posted with my results :)

Tuxman:
nginx is not documented well, it seems. Is there any comprehensive list of available modules?

Shades:
@f0dder
If memory serves me right, I believe that 40Hz many moons ago mentioned bitnami that will get you completely configured development environments in the shape of a simple installation file. And guess what, Ruby is among them.   

Navigation

[0] Message Index

[#] Next page

[*] Previous page