Forum: Ruby on Rails Frustrated with RoR environment splintering

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Def5baf8afb713e4d7303e795d66d973?d=identicon&s=25 news.gmane,org (Guest)
on 2006-03-31 22:52
(Received via mailing list)
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...
Bc80625db60e9db4394c51d6c1892b49?d=identicon&s=25 Derrick Spell (Guest)
on 2006-03-31 23:10
(Received via mailing list)
Yeah, choice sucks, huh?  If only I had no freedom ....

-Derrick
Bcef7e1dee27bd486dae324e0199fe34?d=identicon&s=25 Jeremy Cowgar (Guest)
on 2006-03-31 23:16
(Received via mailing list)
I love the fact of having WEBrick installed and working w/rails. It
makes development work a breeze, not processes tying things up when
I'm not developing. I thought it was a great idea. I've never worked
w/SCGI or Mongrel. I do know, obviously, we need FCGI. LigHTTPD seems
to be a great server to deploy with. Not everyone loves Apache.

I also do not really see it as splintering. Why splinter and support
MySQL, PostgreSQL, Oracle, MSSQL? *I* only use MySQL, we don't need
the others, focus on better MySQL support, forget the others ;-)

Jeremy
58213d4c1552914aaa20e9cab0010149?d=identicon&s=25 David N. Welton (Guest)
on 2006-03-31 23:16
(Received via mailing list)
Derrick Spell wrote:
> Yeah, choice sucks, huh?  If only I had no freedom ....

Actually, yes, too much choice does suck.  Makes people nervous that
they're not picking the 'right' one.  Especially because those facing
the choice for the first time are almost by definition those most
ill-equipped to make the decision.

http://journal.dedasys.com/articles/2006/02/18/max...

Although I don't think that in this case, things are that bad... it
doesn't take long to figure out what's what.

--
David N. Welton
- http://www.dedasys.com/davidw/

Linux, Open Source Consulting
- http://www.dedasys.com/
Bc80625db60e9db4394c51d6c1892b49?d=identicon&s=25 Derrick Spell (Guest)
on 2006-03-31 23:16
(Received via mailing list)
lol .... i just noticed you called mod_perl robust.  Can anyone say mp2?
675475d0b65710be6d992eb5eb2c61c2?d=identicon&s=25 Gregory Seidman (Guest)
on 2006-03-31 23:19
(Received via mailing list)
On Fri, Mar 31, 2006 at 10:20:15AM -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???

Scgi, fcgi, fcgid, and mod_ruby are not Rails-specific. Work has been
done
to allow Rails to work with any of them (except mod_ruby) because their
suitability depends on a variety of things, including the platform.
WEBrick
also predates RoR, I believe, and it is only intended for development
(for
which it is well-suited). Lighttpd exists to provide good performance
while
being more loosely integrated with (or not requiring at all) Apache than
the various CGI methods. Mongrel is the new kid on the block, and may
wind
up replacing WEBrick and/or lighthttpd.

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

Do your development under WEBrick. The appropriate deployment option
will
be obvious based on your particular system's constraints.

} 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.

You should certainly become knowledgeable about Apache integration,
then.
Personally, I have been happy with mod_fcgid under Apache2. Then again,
I
don't do real deployment.

} Just my $.02...

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.

It would be nice to find a single document that covered all possible
deployment options and how to go about them. AFAIK, though, it doesn't
exist. Feel free to write one. You probably won't have enough knowledge
to
fill in all the options, but you can fill in what you know and leave the
skeleton open for submissions. Here's an outline you could start from:

I) Introduction
II) Choices you must make
   - What platform (Windows, *nix)?
   - Virtual host or path?
   - Integrate with Apache?
     - Apache1 or Apache2?
   ? integrate with IIS?
III) Apache integration options
   A) mod_proxy
      1) rewrite rules
      2) lighttpd
      3) mongrel
   B) mod_scgi (I think)
   C) mod_fcgi
   D) mod_fcgid
IV) Standalone options
   A) WEBrick
   B) lighttpd
   C) mongrel
???) IIS integration options???
   ???

--Greg
A8c8fc2c6460e2ebed426f9f51726fc5?d=identicon&s=25 Ross (Guest)
on 2006-03-31 23:25
(Received via mailing list)
news.gmane,org wrote:
> Just my $.02...
My impression is that *FastCGI* is shaping up to be that environment of
record, and it works just fine with Apache, right?
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-03-31 23:25
(Received via mailing list)
On Mar 31, 2006, at 10:20 AM, 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???

mod_perl isn't particularly scalable, in and of itself.

Now, don't get me wrong, I *love* mod_perl. It gives
great performance on dynamic requests and allows Apache
mods to be written in Perl.

However, to scale a mod_perl app, it's generally
understood that you need a static+proxy front-end
passing dynamic requests back to mod_perl backends
because the mod_perl instances are so large that
you cannot handle a reasonable number of client
HTTP connections if you're using mod_perl alone.

So, this *new* community is feeling out the options.

Everything about Rails is new to most peopleat least
to some degree. MVC, ORM, Ruby, etc. I'm delighted
to have learned about Lighttpd, and squeal with
delight at the thought of having zero configuration
backend deployments with mongrel.

Eventually a consensus will emerge. Be patient.

--
-- Tom Mornini
8716cce9a7b721786e5425b8cc1f9951?d=identicon&s=25 sean lynch (Guest)
on 2006-03-31 23:52
WEBrick is really the only thing that is part of rails.

The rest of the things you mention do not ship with Rails. They are
external programs that do things like serve web requests.

Your remark is kind of like asking why Rails runs on Linux, BSD, OS/X,
and Windows. Or Why does Rails work with Oracle, Postgres, mySQL, and
other databases.

Should Rails developers concentrate on one OS or on one DB? Why should
they concentrate on one webserver (other than WEBrick)?

It works with them because they exist and people use them in their
environments.

That's open source for you. A developer tries Rails and says 'Gee that's
nice, but I wish it worked with ADAbase...' Next thing you know the
developer writes the code and Rails works with ADAbase.

Now If you are learning rails, just stick with one stack at first. use
the DB you are familiar with, and the web server you are familiar with.
Then, if you ever become disatisfied, either write code to make your
stack better, or try an alternate!

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...
Def5baf8afb713e4d7303e795d66d973?d=identicon&s=25 Seth Brundle (Guest)
on 2006-04-01 00:27
(Received via mailing list)
> However, to scale a mod_perl app, it's generally
> understood that you need a static+proxy front-end
> passing dynamic requests back to mod_perl backends
> because the mod_perl instances are so large that
> you cannot handle a reasonable number of client
> HTTP connections if you're using mod_perl alone.

I have served several 10's of millions of pageviews daily for 3 years,
currently averaging 70 Mbps network, on 4 generic dual-xeon linux
servers running mod_perl exclusively.

My average delay budget is .3 seconds per page.
I have never used this proxy method and never had a scaling problem with
mod_perl.

However, turn on Apache::Reload (which essentially converts your
mod_perl to
CGI),
and it will throttle my NetApp 720's.

When it comes to scaling websites, practice trumps theory every time.
Def5baf8afb713e4d7303e795d66d973?d=identicon&s=25 Seth Brundle (Guest)
on 2006-04-01 00:45
(Received via mailing list)
> Yeah, choice sucks, huh?  If only I had no freedom ....
>
> -Derrick

Well, this was the expected argumentative response.
Why so predictable?

Variety is of course great, but for those of us who arent tinkerers, but
production engineers responsible to existing large-scale sites, existing
system administrative infrastructures, and and websites that god-forbid
require other webserver features besides RoR, we need the community to
put
its stamp of approval on a well-maintainted, industrial-strength Apache
solution for RoR with persistant interpreter and database connection
support.

The problem with the community not having this thrust is that as
engineers
we dont know in which direction to move - we dont want to end up on a
platform like FastCGI where the maintainer dissapears for 2 years. Where
will fcgi or SCGI be in 2 years?

Here's an example - i tried to install fcgi in Apache 2.2, only to find
out
it doesnt build - turns out that someone submitted the patch to the
maintainer MONTHS ago, and it still hasnt been rolled into the fcgi
code,
nor is it mentioned on the fcgi site.

fcgi - better then fastcgi, maybe- but it looks like we cant expect it
to be
maintained much better.

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.

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.
Def5baf8afb713e4d7303e795d66d973?d=identicon&s=25 Seth Brundle (Guest)
on 2006-04-01 00:48
(Received via mailing list)
>From what I understand FastCGI has not been maintained for 2 years and that
FCGI is perferred.


"Ross" <ross@karchner.com> wrote in message
news:e0k61h$ag4$1@sea.gmane.org...
48b01d623385cfb71a464af7bc37d607?d=identicon&s=25 Michael Moulton (lordbodak)
on 2006-04-01 00:52
Seth Brundle wrote:
> The problem with the community not having this thrust is that as
> engineers
> we dont know in which direction to move - we dont want to end up on a
> platform like FastCGI where the maintainer dissapears for 2 years. Where
> will fcgi or SCGI be in 2 years?

You're right, but... FastCGI is not Rails.  fcgi and SCGI are not Rails.
The advantage to having all this flexibility is that if the maintainer
of one of those disappears for two years, you still have Rails and a
variety of other platforms to run it on.

If Rails settled on FCGI and FCGI's maintainers all gave up, where would
we be then?
A8c8fc2c6460e2ebed426f9f51726fc5?d=identicon&s=25 Ross (Guest)
on 2006-04-01 00:57
(Received via mailing list)
Seth Brundle wrote:
>>>of Apache environment, rather then splintering all over the place with
>>
>>My impression is that *FastCGI* is shaping up to be that environment of
>>record, and it works just fine with Apache, right?

I meant the protocol, not a particular implementation.

But yeah, I think you're right about which is the preffered
implementation for apache.
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 Pat Maddox (pergesu)
on 2006-04-01 01:00
(Received via mailing list)
On 3/31/06, Seth Brundle <brundlefly76@hotmail.com> wrote:
> The problem with the community not having this thrust is that as engineers
> we dont know in which direction to move - we dont want to end up on a
> platform like FastCGI where the maintainer dissapears for 2 years. Where
> will fcgi or SCGI be in 2 years?

The questions you've asked are akin to, "Apache might not be
maintained in two years, so why should I use linux?"  In short - it
doesn't make a lot of sense.  As others have pointed out,
FastCGI/FCGI/SCGI are not Rails.

Rails+lighttpd+fcgi has proven itself in production for quite a while.
 I don't know about SCGI, as I haven't used it yet.  So give it a
shot.  If FCGI falls off the map somewhere down the road, it's
probably due to a better replacement, and if not, there's enough Rails
use now that we will come up with some way of making it work.

It doesn't make sense to avoid Rails because of uncertainty with FCGI,
just as it makes no sense to avoid Linux due to uncertainty with
Apache.

Pat
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-04-01 01:03
(Received via mailing list)
On Mar 31, 2006, at 2:24 PM, Seth Brundle wrote:

>> However, to scale a mod_perl app, it's generally
>> understood that you need a static+proxy front-end
>> passing dynamic requests back to mod_perl backends
>> because the mod_perl instances are so large that
>> you cannot handle a reasonable number of client
>> HTTP connections if you're using mod_perl alone.
>
> I have served several 10's of millions of pageviews daily for 3 years,
> currently averaging 70 Mbps network, on 4 generic dual-xeon linux
> servers running mod_perl exclusively.

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.

Doubly so if you're tying up a mod_perl process doing SSL!

Hey, don't take my word for it, go directly to the source!

http://tinyurl.com/go8bp

> My average delay budget is .3 seconds per page. I have never used this
> proxy method and never had a scaling problem with mod_perl.

I'd humbly suggest that you'd get far better performance (with existing
hardware!) if you went to a two phased setup.

> However, turn on Apache::Reload (which essentially converts your
> mod_perl to
> CGI), and it will throttle my NetApp 720's.
>
> When it comes to scaling websites, practice trumps theory every time.

Yes, I agree. That's why I'm speaking from experience the same as you
are.

--
-- Tom Mornini
Def5baf8afb713e4d7303e795d66d973?d=identicon&s=25 Seth Brundle (Guest)
on 2006-04-01 01:31
(Received via mailing list)
> You're right, but... FastCGI is not Rails.  fcgi and SCGI are not Rails.
> The advantage to having all this flexibility is that if the maintainer
> of one of those disappears for two years, you still have Rails and a
> variety of other platforms to run it on.
>
> If Rails settled on FCGI and FCGI's maintainers all gave up, where would
> we be then?

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 cant put a web project in production which might need to switch either
webservers(!!) or
be sent back to CGI tommorrow because its Apache persistance solution
'fell
out of favor'.

This should not be an argumentative concept to anyone with large-scale
production web applications.
Def5baf8afb713e4d7303e795d66d973?d=identicon&s=25 Seth Brundle (Guest)
on 2006-04-01 01:43
(Received via mailing list)
> 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.

This is what is called 'a successful scalable solution'.

When I worked for Yahoo!, we were 'real efficient' - we developed most
dynamic content in Apache C modules!
Oh the memory we saved!!!

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!!

Guess what? Yahoo! uses PHP now ;)
Def5baf8afb713e4d7303e795d66d973?d=identicon&s=25 Seth Brundle (Guest)
on 2006-04-01 01:52
(Received via mailing list)
> 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.
>
> Doubly so if you're tying up a mod_perl process doing SSL!
>
> Hey, don't take my word for it, go directly to the source!

Why dont you go to Slashdot?
Slashdot runs dynamic content all day long over mod_perl, and its
*links*
crash production sites daily.
55428cbf149e35dd4b65f1d019d04139?d=identicon&s=25 Matthew Palmer (Guest)
on 2006-04-01 02:16
(Received via mailing list)
On Fri, Mar 31, 2006 at 03:27:06PM -0800, Seth Brundle wrote:
> I cant put a web project in production which might need to switch either
> webservers(!!) or be sent back to CGI tommorrow because its Apache
> persistance solution 'fell out of favor'.

Software doesn't rot.  If you choose a solution that works for you, then
it
will continue to work for you.  Security issues you can patch, and when
you
do need to migrate to get some new feature, you'd have to do a whole
pile of
work to migrate no matter what you were switching between -- sensible
upgrade paths are the exception, not the rule.

- Matt
55428cbf149e35dd4b65f1d019d04139?d=identicon&s=25 Matthew Palmer (Guest)
on 2006-04-01 02:22
(Received via mailing list)
On Fri, Mar 31, 2006 at 02:43:04PM -0800, Seth Brundle 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
55428cbf149e35dd4b65f1d019d04139?d=identicon&s=25 Matthew Palmer (Guest)
on 2006-04-01 02:34
(Received via mailing list)
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
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-04-01 03:38
(Received via mailing list)
On Mar 31, 2006, at 3:27 PM, Seth Brundle 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 Mornini
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-04-01 03:41
(Received via mailing list)
On Mar 31, 2006, at 3:49 PM, Seth Brundle 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 Mornini
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-04-01 03:44
(Received via mailing list)
On Mar 31, 2006, at 3:41 PM, Seth Brundle 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 ;)

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 Mornini
4005a47a8f2ceee49670b920593c1d52?d=identicon&s=25 Ben Munat (Guest)
on 2006-04-01 08:29
(Received via mailing list)
Tom Mornini 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!
>
> http://tinyurl.com/fgcfq
>
Uh, well doesn't that mean that it went away before? ;-)

b

PS: sorry Tom... couldn't resist

PPS: oh yeah... I'm that annyoing container junkie: container,
container, container!
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-04-01 09:11
(Received via mailing list)
On Mar 31, 2006, at 10:28 PM, Ben Munat 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!
>> http://tinyurl.com/fgcfq
> Uh, well doesn't that mean that it went away before? ;-)

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 Mornini
9d7d8ef2179661d6b30e180fa588cd45?d=identicon&s=25 Calle Dybedahl (Guest)
on 2006-04-01 09:11
(Received via mailing list)
>>>>> "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 Dybedahl <calle@cyberpomo.com>
		 http://www.livejournal.com/users/cdybedahl/
    "Rational thought. It's an acquired taste." -- Gunn, Angel: the
Series
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-04-01 10:21
(Received via mailing list)
On Mar 31, 2006, at 11:09 PM, Calle Dybedahl 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 Mornini
4005a47a8f2ceee49670b920593c1d52?d=identicon&s=25 Ben Munat (Guest)
on 2006-04-01 20:27
(Received via mailing list)
Tom Mornini wrote:
> On Mar 31, 2006, at 10:28 PM, Ben Munat 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
719c6d09fe6f1ccdbedee2bd90aa86e5?d=identicon&s=25 Jeff Reese (Guest)
on 2006-04-01 21:49
Gregory Seidman 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.
6f7c877de704c7cc03c8a3b2dc52df92?d=identicon&s=25 Carmen --- (carmen)
on 2006-04-01 23:18
> 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..
A63764f318f10379c8b51349b757cf4b?d=identicon&s=25 Jay Levitt (Guest)
on 2006-04-01 23:31
(Received via mailing list)
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
A63764f318f10379c8b51349b757cf4b?d=identicon&s=25 Jay Levitt (Guest)
on 2006-04-01 23:43
(Received via mailing list)
On Fri, 31 Mar 2006 15:41:02 -0800, Seth Brundle 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 Levitt
E041c55ecdb461902f5dab69e19fe4df?d=identicon&s=25 John Smith (Guest)
on 2006-04-01 23:48
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).
235c58ad566abb4c7979bc7033e9882c?d=identicon&s=25 David Morton (Guest)
on 2006-04-02 01:52
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ben Munat 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 Morton
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-----
This topic is locked and can not be replied to.