Would you bother to setup a fastcgi for a “intranet accessible”
application
that is like to get < 100 hits a day?
David
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
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
[email protected]
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
509-577-7732
[email protected]
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. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
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
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
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. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
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
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
On 3/4/06 7:14 AM, “Justin F.” [email protected] 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
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
On 3/4/06 1:04 PM, “Ben M.” [email protected] 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/HttpHandler.html
http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpRequest.html
http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpResponse.html
http://mongrel.rubyforge.org/rdoc/classes/Mongrel/HttpServer.html
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
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
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
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
[email protected]
http://pearsonedmeasurement.com