Forum: Ruby on Rails Webrick in production?

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.
David C. (Guest)
on 2006-02-27 12:05
(Received via mailing list)
Would you bother to setup a fastcgi for a "intranet accessible"
application
that is like to get < 100 hits a day?

David
Michael T. (Guest)
on 2006-02-27 12:30
(Received via mailing list)
It might be, but you also might want to look into Mongrel
http://mongrel.rubyforge.org/.

Michael
Craig W. (Guest)
on 2006-02-27 16:58
(Received via mailing list)
On Mon, 2006-02-27 at 05:01 -0500, David C. wrote:
> Would you bother to setup a fastcgi for a "intranet accessible" application
> that is like to get < 100 hits a day?
>
----
wasn't that difficult to set up actually - if you are asking apache.cgi
vs. apache.fcgi

If you are asking apache.fcgi vs. webrick, the I would say yes because
apache is a service where webrick is an application and requires user
intervention (start/stop/cleanup etc.)

Craig
Ezra Z. (Guest)
on 2006-02-27 19:25
(Received via mailing list)
On Feb 27, 2006, at 2:28 AM, Michael T. wrote:

> It might be, but you also might want to look into Mongrel
> http://mongrel.rubyforge.org/.
>
> Michael
> _______________________________________________
> Rails mailing list
> removed_email_address@domain.invalid
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


	Yes, I highly reccomend mongrel for just this type of thing. It has
a comand line interface to start it as a service or daemon and then
stop or restart it later. And it is performing very very well in my
tests. I think its perfect for intranet type apps like this.

Cheers-
-Ezra Z.
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
removed_email_address@domain.invalid
Eric H. (Guest)
on 2006-02-27 21:38
(Received via mailing list)
On Feb 27, 2006, at 6:56 AM, Craig W. wrote:

> If you are asking apache.fcgi vs. webrick, the I would say yes because
> apache is a service where webrick is an application and requires user
> intervention (start/stop/cleanup etc.)

Lies!

Just have it daemonize itself.

I serve over two million image hits a day via WEBrick and startup and
shutdown are handled by FreeBSD's rc.subr just like apache.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Conrad T. (Guest)
on 2006-02-27 21:56
(Received via mailing list)
Hi, this is very good information in terms of benchmarks because I
definitely need to provide similar information to clients when I
recommend RoR.

-Conrad
Ben M. (Guest)
on 2006-02-28 07:54
(Received via mailing list)
Eric H. wrote:
> I serve over two million image hits a day via WEBrick and startup and
> shutdown are handled by FreeBSD's rc.subr just like apache.

So what about the mythical "mutex on each request" that WEBrick has? You
don't ever have
long page waits? It never crashes? Is this one instance of WEBrick
handling all those hits?

I ask because I've wished for a web container to run my rails apps in,
and WEBrick could
be that other than for all the stern warnings about it not being
suitable for production.
(Been meaning to check out Mongrel too... but I'm still on 1.82)

b
Eric H. (Guest)
on 2006-02-28 23:25
(Received via mailing list)
On Feb 27, 2006, at 9:55 PM, Ben M. wrote:

> Eric H. wrote:
>> I serve over two million image hits a day via WEBrick and startup
>> and  shutdown are handled by FreeBSD's rc.subr just like apache.
>
> So what about the mythical "mutex on each request" that WEBrick has?

I don't know about Rails, but no such thing exists in WEBrick.  (Note
that I'm not using WEBrick to serve Rails requests, I'm using it for
"image hits".)

> You don't ever have long page waits?

Do you consider ~ 50-60ms long?  A typical request is handled in the
10ms-25ms range.

There still may be a few optimizations I can make in the image lookup
code that will reduce the standard deviation.

> It never crashes?

USER   PID %CPU %MEM   VSZ   RSS  TT  STAT STARTED      TIME COMMAND
www   6036  2.0  0.5 25268 10040  ??  S    Sun11PM  23:00.12 /usr/
local/bin/rub

No.

> Is this one instance of WEBrick handling all those hits?

I fork 8 processes per machine on three machines to distribute the
load a little better since static image requests are very bursty and
I have machines with multiple CPUs.  I may cut it back to 6 or 4
processes now that I correctly handle conditional HTTP requests to
save on memory.  (2% CPU is high for these processes.)

> I ask because I've wished for a web container to run my rails apps
> in, and WEBrick could be that other than for all the stern warnings
> about it not being suitable for production.

I can't tell you if Rails + WEBrick is suitable for serving high-
volume traffic or not, I haven't looked.  WEBrick itself is certainly
suitable for high-volume traffic when you write your servlets
correctly (and, possibly, fork()).  Rails may simply be missing
something that allows it to run well multi-threaded.

> (Been meaning to check out Mongrel too... but I'm still on 1.82)

If I can serve static images with a lookup in MogileFS in 12ms and
Apache can serve static content without any lookups straight off disk
in 6ms I don't see what benefit Mongrel would give me.

My speed boost comes from using sendfile().  WEBrick makes it easy to
match a URL with a File so I can pass it right in.

--
Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Ben M. (Guest)
on 2006-03-01 11:05
(Received via mailing list)
Eric H. wrote:
> On Feb 27, 2006, at 9:55 PM, Ben M. wrote:
>> So what about the mythical "mutex on each request" that WEBrick has?
>
> I don't know about Rails, but no such thing exists in WEBrick.  (Note
> that I'm not using WEBrick to serve Rails requests, I'm using it for
> "image hits".)

Duh... helps if I read more carefully. The passage in AWDWR is: [WEBrick
is] not a
particulary attractive approach for heavy-duty use. One of the reasons
is the lack of
thread safety in *ActionPack* (emphasis mine), which forces WEBrick to
place a mutex at
the gate of dynamic requests..."

So, it is a problem in rails...... on the other hand, this is a rails
list so I can see
how I'd be thinking about that. :-)

Oh and I'm mostly interested in mongrel as a "container" (ala a Java
servlet container)
for my rails apps... I'm starting to see how that's not totally
essential, but I think
it'll be nice to have as an option.

b
Justin F. (Guest)
on 2006-03-04 14:16
(Received via mailing list)
Ben M. wrote:
> reasons is the lack of thread safety in *ActionPack* (emphasis mine),
> which forces WEBrick to place a mutex at the gate of dynamic requests..."
>
> So, it is a problem in rails...... on the other hand, this is a rails
> list so I can see how I'd be thinking about that. :-)
>
> Oh and I'm mostly interested in mongrel as a "container" (ala a Java
> servlet container) for my rails apps... I'm starting to see how that's
> not totally essential, but I think it'll be nice to have as an option.

As I understand it, the mutex is in Rails, and it affects Mongrel in
exactly the same way that it affects WEBrick.

   Justin
Zed S. (Guest)
on 2006-03-04 18:05
(Received via mailing list)
On 3/4/06 7:14 AM, "Justin F." <removed_email_address@domain.invalid> wrote:

>> is] not a particulary attractive approach for heavy-duty use. One of the
>> reasons is the lack of thread safety in *ActionPack* (emphasis mine),
>> which forces WEBrick to place a mutex at the gate of dynamic requests..."
>>
>> So, it is a problem in rails...... on the other hand, this is a rails
>> list so I can see how I'd be thinking about that. :-)
>
> As I understand it, the mutex is in Rails, and it affects Mongrel in
> exactly the same way that it affects WEBrick.
>

Yes, Mongrel has to use a "grand mutex" around the Dispatcher.dispatch
in
order to prevent Rails from going crazy.  Rails just isn't thread safe.

One thing you can do in both Mongrel (and WEBrick) is if there's a
particular little part of your Rails application that needs to run very
fast, then write a handler that runs right inside Mongrel.  This then
moves
the processing out reducing the overhead and giving you full threaded
operation (which you have to be careful of yourself).

Zed A. Shaw
http://www.zedshaw.com/
Ben M. (Guest)
on 2006-03-04 20:03
(Received via mailing list)
Zed S. wrote:
>>>reasons is the lack of thread safety in *ActionPack* (emphasis mine),
>
> One thing you can do in both Mongrel (and WEBrick) is if there's a
> particular little part of your Rails application that needs to run very
> fast, then write a handler that runs right inside Mongrel.  This then moves
> the processing out reducing the overhead and giving you full threaded
> operation (which you have to be careful of yourself).

Wow. This just took the wind out of my sails.

So, I should pretty much forget ever seeing a servlet container for
rails? Sorry Zed, but
this pretty much brings me around to Eric's point of view: why bother
creating Mongrel at all?

b
Zed S. (Guest)
on 2006-03-04 21:34
(Received via mailing list)
On 3/4/06 1:04 PM, "Ben M." <removed_email_address@domain.invalid> wrote:

> Zed S. wrote:

>
> So, I should pretty much forget ever seeing a servlet container for rails?
> Sorry Zed, but
> this pretty much brings me around to Eric's point of view: why bother creating
> Mongrel at all?
>

Well, first off, this threading issue is Rail's problem, not Mongrel's.
Nitro and Camping don't have this problem AFAIK.

Second, Mongrel already is a "servlet container" for Ruby web
applications.
It has all the things you need to write your own web applications
directly.
In fact, that's why it supports Nitro and Camping.  The Nitro and
Camping
folks just grabbed Mongrel and wrote their own handlers to support their
web
framework.

Take a look at the docs for:

http://mongrel.rubyforge.org/rdoc/classes/Mongrel/...
http://mongrel.rubyforge.org/rdoc/classes/Mongrel/...
http://mongrel.rubyforge.org/rdoc/classes/Mongrel/...
http://mongrel.rubyforge.org/rdoc/classes/Mongrel/...

See?  Very much like your average "servlet container".  The only real
thing
missing is the ability to load apps from gems or a directory (which is
in
the works as we speak).


Now, as for why bother writing Mongrel (not sure if Eric really said
that):

Why bother writing Ruby?  I mean, didn't we already have C?

For people who want the current best practice I say go with FastCGI.
FastCGI however is a royal pain in the ass to manage (YMMV).  The
alternative way is to serve your applications directly using WEBrick.
This
gives you the advantage of the flexible simplicity of HTTP (think load
balancers), but WEBrick is incredibly slow.

Mongrel tries to be right in this niche:  The speed of FastCGI with the
simplicity of WEBrick for hosting.  For many people the fact that
Mongrel
supports win32 just as well as POSIX systems is a big win.  I've also
heard
other people like it for development since it's quicker than WEBrick but
just as easy to start.  Other folks are using it to serve minor intranet
sites directly since they don't need to service a huge load but don't
want
things slow for the few people they have.

Finally, I've been working on a best practice document:

http://mongrel.rubyforge.org/docs/lighttpd.html

That will tell folks how to hook up a lighttpd+mongrel+memcache setup
that
should be competitive with the current crop of FastCGI configurations.

Anyway, how else would I get to play with a Ragel HTTP parser and
ternary
search tries?  :-)


Zed A. Shaw
http://www.zedshaw.com/
Ben M. (Guest)
on 2006-03-04 22:23
(Received via mailing list)
Thanks for the explanation Zed. I see that the threading issue is with
Rails and not
Mongrel and there's not much you can do about that. That's still
frustrating, but well,
I'll just have to deal... or look into other Ruby web frameworks.

I wish there was a bit more energy behind the Nitro effort... more docs
would be nice. And
actually, even with more docs I just don't see them having the same
level of
crunchy-goodness as Rails any time soon.

Oh, and for the record, I may have misrepresented what Eric said... he
said "I don't see
what benefit Mongrel would give me" but really he was simply talking
about speed at
serving images... nothing involving thread issues, ease of app
deployment, running
multiple apps, or any other points that I would consider pertinent to
the servlet
container topic.

b
Craig W. (Guest)
on 2006-03-04 22:56
(Received via mailing list)
On Sat, 2006-03-04 at 12:23 -0800, Ben M. wrote:
> the same level of
> crunchy-goodness as Rails
----
aren't there enough train/rails metaphors to handle these things that we
now have to add breakfast cereals to the mix?

;-)

Craig
John-Mason P. Shackelford (Guest)
on 2006-03-04 23:26
(Received via mailing list)
I wonder if anyone would clarify what is meant by the assertion that
ActionPack is not  thread-safe. A comment in the Rails source seems to
indicate otherwise. I have not read enough of the source myself to
understand what all of the issue are.

//root/trunk/actionpack/lib/action_controller/base.rb

lines 257-261

> # Controls whether the application is thread-safe, so multi-threaded servers like 
WEBrick know whether to apply a mutex
> # around the performance of each action. Action Pack and Active Record are by default > 
thread-safe, but many applications
> # may not be. Turned off by default.
> @@allow_concurrency = false
> cattr_accessor :allow_concurrency

--
John-Mason Shackelford

Software Developer
Pearson Educational Measurement

2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
removed_email_address@domain.invalid
http://pearsonedmeasurement.com
This topic is locked and can not be replied to.