Rails - Mar 2006 - Frustrated with RoR environment splintering

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

Yeah, choice sucks, huh?  If only I had no freedom ....

-Derrick

On Mar 31, 2006, at 1:20 PM, 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...
>
>
>
>
>
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

lol .... i just noticed you called mod_perl robust.  Can anyone say mp2?


On Mar 31, 2006, at 1:20 PM, 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...
>
>
>
>
>
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

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

On Mar 31, 2006, at 1:20 PM, 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...
>
>
>
>
>
>
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

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/maximizers-satisficers-and-programming-languages

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/

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

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

My impression is that *FastCGI* is shaping up to be that environment of 
record, and it works just fine with Apache, right?

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

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

-- 
Posted via http://www.ruby-forum.com/.

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

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

>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...
> 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...
>
>
> My impression is that *FastCGI* is shaping up to be that environment of 
> record, and it works just fine with Apache, right?

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?

-- 
Posted via http://www.ruby-forum.com/.

Seth Brundle wrote:
>>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...
> 
>>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...
>>
>>
>>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.

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

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

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

> 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 ;)

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

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

-- 
Another Fine Product From The Nonsense Factory.

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

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


-- 
<Igloo> I remember going to my first tutorial in room 404. I was most
upset
when I found it.

On Mar 31, 2006, at 3:27 PM, Seth Brundle wrote:
>> 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 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

On Mar 31, 2006, at 3:49 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.
>>
>> 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.
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

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.
> 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 ;)
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

Tom Mornini wrote:
> On Mar 31, 2006, at 3:27 PM, Seth Brundle wrote:
> 
>>> 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 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!

On Mar 31, 2006, at 10:28 PM, Ben Munat wrote:
> Tom Mornini wrote:
>> On Mar 31, 2006, at 3:27 PM, Seth Brundle wrote:
>>>> 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 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

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

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

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

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.

-- 
Posted via http://www.ruby-forum.com/.

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

-- 
Posted via http://www.ruby-forum.com/.

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

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

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


-- 
Posted via http://www.ruby-forum.com/.

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