Frustrated with RoR environment splintering

Rails
21

On Fri, Mar 31, 2006 at 10:20:15AM -0800, news.gmane,org wrote:

Its very unlikely I would ever get a contract to work on any webserver
except Apache, so it would seem logicaly to focus all our efforts to make
Apache the ‘production environment of record’ for RoR.

“It’s very unlikely I would ever get a contract to work on any language
except PHP, so it would seem logical to focus all our efforts to make
PHP
the ‘production language of record’ for PoR.”

You could also perform a very similar transformation by OS.

The difficulty is that what seems absolute and completely beyond doubt
for
you isn’t necessarily what the rest of the world sees. You can take
Ruby
yourself as an example there – in Japan, apparently, it’s has insane
popularity. Until Rails (and to a lesser extent the Prags) came along,
nobody in the English-speaking world had ever really heard of it or used
it
(it rated a mention at the same level as say SmallTalk or OCaml). It
would
no doubt have seemed ridiculous to many to base a web framework like
Rails
on such a poorly-supported language – and yet, here we all are, and
Ruby
brings some fairly unique features to the table to enable some of Rails’
coolest features.

Give it a year and you might just be able to switch a few nouns around
in
the above paragraph to describe the Rails hosting landscape. If Rails
prematurely “settles” on one solution, then we’ll never know if
environment
X is insanely better for Rails deployment. I’ve switched a lot of stuff
to
lighty (both Rails and otherwise) from being a die-hard Apacheite, and
everyone here is loving it. I’m keeping an eye on Mongrel, too, as it
looks
like it could do good things.

  • Matt
22

On Mar 31, 2006, at 3:27 PM, Seth B. wrote:

Thats exactly my point - when I chose mod_perl it was not risky
because both
the Apache Foundation and the Perl community were strongly behind
it. It wasnt
‘going away’.

That isnt clear with any of the current Apache implementation
persistance
solutions for RoR.

I don’t think that’s a fair statement.

mod_fcgi isn’t about to “go away”, in fact, it’s currently making a
comeback!

http://tinyurl.com/fgcfq

–
– Tom M.

23

On Mar 31, 2006, at 3:49 PM, Seth B. wrote:

Slashdot runs dynamic content all day long over mod_perl, and
its links crash production sites daily.

Apparently you didn’t follow the links at all.

I never said, and never will say that mod_perl isn’t the right
solution for dynamic requests!

–
– Tom M.

24

On Fri, Mar 31, 2006 at 02:43:04PM -0800, Seth B. wrote:

With mod_perl, it was clear the community supported it as the Apache
solution of record for Perl, so after a year or two production engineers
felt safe moving in that direction. But with Ruby On Rails, the long-term
supported solution we can invest in is still completely unclear.

As you said yourself in another posting, some years ago, C was clearly
the
community-supported programming language of choice. Now it isn’t.
Things
change.

Personally, I find the fact that Rails is completely happy supporting
several different dispatch methods quite comforting, from a
survivability
point of view. If one implementation or method goes completely down the
tubes (or is shown, suddenly, to have a major crippling flaw) I can
move.
Monocultures are bad, no matter where they are.

And yes, there are serious reprecussions for those of us with 100,000 plus
lines of code to be invested in a commercial project that the platform we
select does not fall out of favor in 18 months.

What’s this “falling out of favour” thing you keep talking about? You
don’t
have to follow the herd (hurd?) on everything. You have the source, you
apparently have the resources – if nobody else is willing, you can keep
something that’s been abandoned in maintenance mode yourself until a
suitable replacement comes along.

  • Matt
25

On Mar 31, 2006, at 3:41 PM, Seth B. wrote:

Seems a shame to use a very large (relatively) mod_perl instance
to feed
a slow client connection. Particularly so if the request is entirely
static and requires no mod_perl usage.

LOL Tom, if your website serves 70 Mbps of dynamic content over 4
linux
servers and RADs easily and is rock stable and serves dynamic
pages in
.3s for 3 years, there is no ‘shame’ to be had.

Sigh.

I didn’t say the performance was shameful, I said it’s a shame to be
wasteful.

This is what is called ‘a successful scalable solution’.

4 boxes? How scalable is that?

Look, you’re getting performance that works for you, and I’m happy for
you. I love mod_perl, but it IS A SHAME to use a mod_perl process
to handle static and SSL content.

walking to his cube (hoping to god he was there), getting an 'oh

Guess what? Yahoo! uses PHP now :wink:

This is so completely irrelevant, I just don’t know how respond.

You’re speaking of programmer productivity -vs- runtime efficiency,
where I’m speaking about something that can radically improve
scalability with your existing code base.

–
– Tom M.

26

On Mar 31, 2006, at 10:28 PM, Ben M. wrote:

If Rails settled on FCGI and FCGI’s maintainers all gave up,
That isnt clear with any of the current Apache implementation
persistance
solutions for RoR.
I don’t think that’s a fair statement.
mod_fcgi isn’t about to “go away”, in fact, it’s currently making
a comeback!
Peak Obsession
Uh, well doesn’t that mean that it went away before? :wink:

Well, no, not really. It’s never been part of the Apache distribution
before!

Has any other piece of the Apache distribution ever just vanished?

PS: sorry Tom… couldn’t resist

No problem!

PPS: oh yeah… I’m that annyoing container junkie: container,
container, container!

Mongrel, mongrel, mongrel, mongrel…

–
– Tom M.

27

“news” == news gmane <news.gmane> writes:

Why isnt the RoR community focusing on robust and scalable mod_perl
style of Apache environment

As someone just coming from “robust and scalable mod_perl”, the Rails
way feels like a great relief to me. Trying to run more than one
application in the same mod_perl is Not Fun, in general. It’s all
right if you wrote all the applications yourself so you can make sure
they don’t want difference versions of the same module or stomp on
each other’s global variables, but if it’s applications off the net
you usually end up running one Apache per application anyway.

By sticking each Rails application in an FCGI environment of its own,
this kind of problem just doesn’t exist. Which is nice.

(Now, if I could just figure out how to tell lighttpd to set the
charset to UTF-8 by default like WEBrick does, I’d try that one out
too.)

	     Calle D. <[email protected]>
	 http://www.livejournal.com/users/cdybedahl/
"Rational thought. It's an acquired taste." -- Gunn, Angel: the

Series

28

Tom M. wrote:

we be then?
solutions for RoR.

I don’t think that’s a fair statement.

mod_fcgi isn’t about to “go away”, in fact, it’s currently making a
comeback!

Peak Obsession

Uh, well doesn’t that mean that it went away before? :wink:

b

PS: sorry Tom… couldn’t resist

PPS: oh yeah… I’m that annyoing container junkie: container,
container, container!

29

On Mar 31, 2006, at 11:09 PM, Calle D. wrote:

(Now, if I could just figure out how to tell lighttpd to set the
charset to UTF-8 by default like WEBrick does, I’d try that one out
too.)

I didn’t write this code, and I don’t have the original attribution.

I’m almost certain it came from the Rails Wiki

Put this in application.rb

def set_content_type
if not request.env[‘HTTP_ACCEPT’].nil? and
( request.env[‘HTTP_ACCEPT’].index(‘application/xhtml+xml’) or
request.env[‘HTTP_ACCEPT’].index(’/’) )
headers[‘Content-Type’] = “application/xhtml+xml; charset=utf-8”
else
headers[‘Content-Type’] = “text/html; charset=utf-8”
end
end

And set after_filter for all controllers.

–
– Tom M.

30

Tom M. wrote:

On Mar 31, 2006, at 10:28 PM, Ben M. wrote:

PPS: oh yeah… I’m that annyoing container junkie: container,
container, container!

Mongrel, mongrel, mongrel, mongrel…

Well, I was initially pretty excited about Mongrel but then I keep
hearing talk of running
Mongrel with lighty/apache… and running Mongrel for a specific app
(rather than running
Mongrel and adding/removing apps). All this, along with rails’
single-threaded nature,
have made me somewhat gloomy about ever seeing a real servlet container
for rails.

I do need to spend some more time with Nitro and Camping… maybe they
don’t have the
threading issue. But still, it seems that Mongrel has adopted the “copy
per app” approach
of WEBrick rather than the servlet container approach. I suppose someone
would need to
write a servlet API for Ruby in order to do that (not sure if the CGI
module fulfills that).

b

31

Gregory S. wrote:

I was pretty frustrated when I was trying to figure out deployument for
my first app. I couldn’t figure out what I should use, nor could I
determine how to do what I wanted to do. Eventually I did find the docs I
needed, and all is well. Once you figure it out, you can do it again. The problem is
that there are so many choices, but those choices exist because someone
out
there needed each one of them.

I’ll second this. I’m one of those countless souls that recently
converted to Rails and discovered a renewed sense of freedom in the
philosophy of convention over configuration. Being on “rails” meant that
certain decisions were already made for me and I could concentrate on my
business. I had the freedom to deviate from the track if I needed to but
in most cases I never needed to.

Linux distros, database vendors, and web servers are not part of Rails
but it would be nice if Rails had an opinion about these things just as
it does about so many other aspects of my application.

Discussions of distros, databases, web servers, etc. often devolve into
religous arguments but again, it would be nice to know that there is a
definite, opinionated path that I can follow to get my app into
production that just works. It might not meet all of my needs but I know
that I can stray from the path if I need to.

I’m currently working on getting my first production environment up
using Debian Stable, lighttpd, and mysql. All I want is the ability to
run a single app, send mail through ActionMailer, and manage deployment
via Capistrano. I’ll take notes and see what happens.

32

Linux distros, database vendors, and web servers are not part of Rails
but it would be nice if Rails had an opinion about these things just as
it does about so many other aspects of my application.

im pretty sure its opinion is ‘develop on a mac , using textmate, and
deploy with mongrel, using mysql as your db’. but clearly the fact that
such things are abstracted in a way that you do have choice is an
opinion as well…

i’m not sure ‘splinter’ is the right metaphor for this thread. rails
are usually made out of metal, and you can run an amtrak passenger car,
or a big graffiti-covered box carrying coal, or live cattle, or
whatever, as well…

33

On Fri, 31 Mar 2006 10:20:15 -0800, news.gmane,org wrote:

Why isnt the RoR community focusing on robust and scalable mod_perl style of
Apache environment, rather then splintering all over the place with
lighthttp, mongrel, WEBrick, SCGI, fcgi, etc???

Lurker’s perspective:

I think that if FCGI had been well-supported and stable on multiple OS’s
a
year or two ago, then Rails might have gone in that direction for
production, with Webrick as a handy development server.

However, the Apache FCGI projects appeared to be stalled. So people
started using lighty, and Zed came up with some support for SCGI.
Meanwhile, since Webrick isn’t suitable for production, Zed also came up
with Mongrel, which is significantly faster and could soon be a great
platform for “light production” - or eventually, thanks to the new
corporate funding, for full production.

Meanwhile, Apache 2.2 came with better, newly-resupported FCGI. And
Zed’s
focus is clearly on Mongrel at the moment. So between lowered supply
and
lowered demand, I’m not too sure what will happen with Rails-on-SCGI.

I expect that in a year, Mongrel will have replaced Webrick, and we’ll
have
clustered toward either FCGI or SCGI on both Apache and Lighty - perhaps
depending on which OS you use. Maybe not. I’m just lurking.

Jay

34

On Fri, 31 Mar 2006 15:41:02 -0800, Seth B. wrote:

Mondays were especially fun. You spent 4.5 hours compiling the production
codebase (whether YOUR site was affected by others changes or not), checking
every so often for the inevitable error, checking CVS for the module author,
walking to his cube (hoping to god he was there), getting an ‘oh yeah you
gotta blahblahblsa…’, implementing blahblahblah, resume compile, and then
RESTARTING all your webservers on 4 continents (because you cant update C
modules without a restart!) Then go home and hope to get real work done on
monday.

Oh but the memory we saved

LOL! Sounds like AOL. Everything was written in C on top of our own
custom, non-threaded event-driven kernel, with our own message-queueing
system that derived from our Stratus minicomputer days. We even had to
write our own TCP stack so we could handle over 10,000 simultaneous open
sockets in a single process. Our server-to-client protocol was designed
to
be efficient even at 1200 bps, with different bytecodes for 1-, 2- and
4-byte values, and inherent lookup-free compression of shorter
bytecodes.
It kicked HTML’s ass in both transmission and rendering performance.

The result was a high-performance monster that ran on relatively little
hardware, but was a bitch to develop for, even if you were experienced -
which, of course, no new hires were. And, once Linux came to the
forefront, hardware got much cheaper than developer time.

About a year before I left, a young upstart in Operations decided that,
even though our mail system occupied hundreds of servers on three
platforms
with all sorts of reliable-messaging and failover layers, he was going
to
write a spam filter that ran on a single workstation so he could
correlate
message flows. One workstation. Reading message queues from disk.
In Perl!

Naturally, I laughed, and showed him a design for a multi-server spam
filter, taking advantage of shared-memory queues and caching and staging
and load-balancing whatnot. And he wrote his one-machine spam filter
anyway, and it pretty much singlehandedly saved the mail system from
choking on the billions of spams a day it was receiving. And that’s
when I
knew the old thinking wasn’t useful anymore.

Jay L.

35

news.gmane,org wrote:

Why isnt the RoR community focusing on robust and scalable mod_perl
style of
Apache environment, rather then splintering all over the place with
lighthttp, mongrel, WEBrick, SCGI, fcgi, etc???

Its frustrating as someone who is trying to migrate to RoR.

Its very unlikely I would ever get a contract to work on any webserver
except Apache, so it would seem logicaly to focus all our efforts to
make
Apache the ‘production environment of record’ for RoR.

Just my $.02…

From a security perspective, it is good to have choices in case a patch
isn’t available for a new exploit.

I frequently test the latest Lighttpd-1.4.x in case I need to replace
Apache on short notice. I’m happy with rails-1.1 on Apache 2.0.55 (MPM
Worker) + mod_fcgid-1.08 (patched to keep one dispatch.fcgi ignore
autokill settings) + mod_security-1.9.2 (to block XSS & SQL injection
attacks).

36

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ben M. wrote:

don’t have the threading issue. But still, it seems that Mongrel has
adopted the “copy per app” approach of WEBrick rather than the servlet

This isn’t necessarily bad, as it also can be running as a new user,
which
enhances the security of the app.

David M.
Maia Mailguard - http://www.maiamailguard.com
Morton Software Design and Consulting - http://www.dgrmm.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFELxJTSIxC85HZHLMRAlT9AKCSVqjhyYH5gmbY/mHnLq527q/iVwCgj9AL
AraKTfL0pRs4e3G7RCOFky0=
=p8Ne
-----END PGP SIGNATURE-----