This is the long awaited (like 2 weeks) 0.3.12 release of Mongrel. This
release has received heavier testing than previous releases and supports
a
whole raft of improvements to existing functionality plus some new
stuff.
For those not clued in, Mongrel is a web server written in (mostly)
Ruby.
Check the funny dogs and read the docs about it at http://mongrel.rubyforge.org/. The goal is to create a Ruby HTTP server
to
compete with Apache Tomcat or other Java application servers. The other
goal is to have the speed of FastCGI with the ease of WEBrick.
WHAT’S NEW
The big points of this release are:
The Mongrel::Configurator and Mongrel::Rails::Configurator for simple
configuration (mostly for framework implementers to use).
Dynamically loadable handlers from the GemPlugins system. Next
release
will let you write and add your own handlers.
Chained handlers. That’s right, you can stack a series of handlers on
any
URIs and they’ll be processed in order. This gives you an advanced and
fast
pipe-lined processing system and is already used to implement the
extensive
debugging support Mongrel has.
Debugging, Debugging, Debugging. Try the -B option and then look in
the
log/mongrel_debug logs. I’ll be beefing this up to insane usefulness
for
the 0.3.13 release.
Support for sendfile on FreeBSD, Linux, and Solaris if you install the
ruby-sendfile (http://rubyforge.org/projects/ruby-sendfile) gem. This
is
experimental but already gives a 20% boost on static files.
Additional proper headers for static files from the DirHandler in
order to
allow browsers to cache the content. People using Mongrel for
development
or small sites will love this combined with the sendfile support.
Lots and lots of little tweaks to improve speed and stability.
Mongrel is
starting to hit a wall again with performance so I’ll be looking for new
hot-spots to move to C in the near future.
Initial support for Rails 1.1. Remember if you use Typo it is broken
not
Mongrel. Typo is being frantically fixed so be patient.
Fix for a bad typo on Win32 that prevented people from using
additional
mime types files (stupid Emacs and it’s damn capitalize command being
exactly the same as Copy in every other editor).
Ability to specify a timeout throttling setting and a max number of
concurrent connections with additional attempts at cleaning dead threads
out. Future debugging will help people spot these.
Lots of new Camping support and integration (thanks to Trotter Cashion
for
using Mongrel with Camping like crazy).
A handy -C option for the mongrel_rails script that lets you specify
the
options you’d normally do on the command line as a YAML hash. More on
this
later.
INSTALL
Everyone can go download 0.3.12 from http://rubyforge.org/frs/?group_id=1306
like normal or do the usual “gem install mongrel” or “gem update” to get
the
latest and greatest.
– If you followed pre-release please uninstall first.
NEXT STOP…
The next steps with Mongrel will be to add the capability for users of
Mongrel to write their own Configurator scripts and to test the living
daylights out of it. If you missed my last announcement, Mongrel is
getting commercial sponsorship from EastMedia (http://www.eastmedia.com/) in
partnership with VeriSign (http://www.verisign.com/) for use in a
potentially large scale project. My role in this is to make sure
Mongrel
can handle the required role and will not ever crash. I’ll be spending
the
next few weeks putting out less features and doing more stability and
speed
tweaks. Stay tuned. Should be fun.
This is the long awaited (like 2 weeks) 0.3.12 release of Mongrel.
This
release has received heavier testing than previous releases and
supports a
whole raft of improvements to existing functionality plus some new
stuff.
Minor, minor point:
Installing RDoc documentation for mongrel-0.3.12…
lib/mongrel/rails.rb:135:49: Skipping require of dynamic string: “#
{ops[:cwd]}/config/environment”
I read the website, but I must admit I still don’t see what benefits
Mongrel will bring me. What can it do that fcgi cannot? Is it just an
easier (and maybe faster) way to run rails apps or does it add
functionality that is currently not available?
Fix for a bad typo on Win32 that prevented people from using additional
mime types files (stupid Emacs and it’s damn capitalize command being
exactly the same as Copy in every other editor).
This now works with mongrel_rails_service but not with mongrel_rails
from the command line (I tested it on Windows2003 and OS X). If I start
Mongrel from the command line I get:
mongrel_rails start -m config/mime.yaml
** Starting Mongrel in development mode at 0.0.0.0:3000
** Loading additional MIME types from config/mime.yaml
** Loading additional MIME types from config/mime.yaml
** Starting Rails in environment development …
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready. TERM => stop. USR2 => restart. INT => stop (no
restart).
** Rails signals registered. HUP => reload (without restart). It might
not work well.
** Running 0.0.0.0:3000 listener.
** Mongrel available at 0.0.0.0:3000
Watch the double output for the MIME-stuff.
Installing Mongrel with MIME-support as a service on Windows2003 works
now.
hey, first off thanks - ive been using it locally and i love it, works a
charm
im currently running lighttpd + scgi (cheers again!) and i’m eager to
give
your lighttpd + mongrel proxy setup a bash; one thing though, is
memcached a requirement or just advised/preferred?
this is for running on a vps with 256MB, so resources are at a premium
first thing on memcached’s w3 page is a boot command specifying 2GB ram
which
is scaring the beejesus outta me to say the least… i assume i can get
away
with substantially less than this but do i need it at all in order to
utilise
lighttpd’s cache?
this is for lightweight apps using sqlite3, no fat rdbms’s
any tips before i screw my server are most welcome
I’m using Lighty and Mongrel, but don’t use memcached (nor Lighty’s
cache, which I haven’t heard of (unless it’s the PFM Zed mentions in his
Lighty-Mongrel doc) ).
yeah it’s the power magnet bit - i’m just not really sure if the
“Memcached
The next installment of this document will tell you how to setup a
memcached
so that you can run the lighttpd on a different server from the Mongrel
cluster. Right now they all have to reside on one machine.”
part means anything as far as cacheing using lighttpd is concerned (on
one
machine)
on debian unstable/powerpc:
Building native extensions. This could take a while…
http11.c: In function ?header_done?:
http11.c:95: warning: unused variable ?port?
http11.c:94: warning: unused variable ?host?
http11.c: At top level:
http11.c:25: warning: ?global_interface_value? defined but not used
ext/http11/http11_parser.c: In function ?http_parser_execute?:
ext/http11/http11_parser.c:423: warning: comparison is always true due
to limited range of data type
ext/http11/http11_parser.c:473: warning: comparison is always true due
to limited range of data type
ext/http11/http11_parser.c:491: warning: comparison is always true due
to limited range of data type
ext/http11/http11_parser.c:542: warning: comparison is always true due
to limited range of data type
ext/http11/http11_parser.c:564: warning: comparison is always true due
to limited range of data type
ruby extconf.rb update mongrel
checking for main() in -lc… yes
but seems to work well though.
on debian sarge/686 it successfully installs too, though the report
while compiling show many small errors.
But mongrel_rails start fails with
/usr/lib/ruby/gems/1.8/gems/mongrel-0.3.12/lib/mongrel/rails.rb:28:
uninitialized constant Mongrel::HttpHandler (NameError).
I don’t think I miss a library Ideas ?
I read the website, but I must admit I still don’t see what benefits
Mongrel will bring me. What can it do that fcgi cannot? Is it just an
easier (and maybe faster) way to run rails apps or does it add
functionality that is currently not available?
For one, it’s a nice replacement for webrick, while developing, as it is
much
faster than webrick.
Compared to fcgi, it’s similar, so if you have a working fcgi
environment, it
may be a tougher call. Of interest to me was:
where they said, “Mongrel as a proxy performs just as well as fcgi does,
either
with lighttpd or litespeed, and could easily become an Adios FCGI
thing.”
where they said, “Mongrel as a proxy performs just as well as fcgi does,
either
with lighttpd or litespeed, and could easily become an Adios FCGI
thing.”
After putzing with lighttpd, fcgi, and apache for the better part of a
day on both OSX and Windows, I did the dance of joy when I fired up
mongrel and everything just worked! (on both platforms, I might add).
Our web app will never high hit rates (maybe 10k/day at the outside),
and is 99.5% generated content (little or no static content). While the
hit rate is not high, it must be absolutely stable. Lives won’t exactly
depend on this app, but it is “mission critical”.
The questions I have are
Is there anyone with experience running mongrel for any length of
time, and how stable did it prove itself to be?
Since we are not serving static content, is there any compelling
reason not to use mongrel as is, i.e., without lighttpd or apache?
Bottom line question is: Given the parameters above and the fact that we
do not currently have a fcgi system in place, would you go with
mongrel?
Bottom line question is: Given the parameters above and the fact that we
do not currently have a fcgi system in place, would you go with
mongrel?
I don’t know yet, I’m still evaluating it. Run some benchmarking tests
yourself…
I plan on running tests performance test suite against our system using
mongrel. What I was interested in was stability over time on a real
deployment, if one exists given that mongrel is pretty new.
I just finished putting the finishing touches on the first cut at the
stability release 0.3.12.1. It’s the result of spending this weekend
pounding the hell out of a soon-to-be-production deployment. You can
try it
out with:
This release has mostly tweaks to the HTTP parser and IO so that Mongrel
detects various bad input types and sizes and then boots the bad clients
early.
I just finished putting the finishing touches on the first cut at the
stability release 0.3.12.1. It’s the result of spending this weekend
pounding the hell out of a soon-to-be-production deployment. You can
try it
out with:
This release has mostly tweaks to the HTTP parser and IO so that Mongrel
detects various bad input types and sizes and then boots the bad clients
early.
Zed,
I’ll check it out. We are going through our preliminary pilot phase with
a customer and I’m planning on using mongrel for at least this phase
(100’s of hits a day at most). I’ll run some tests today on the release
and let you know if I run into anything.
BTW, GREAT work on this! Its also great that you’ve been funded to
continue work on it.
My apologies if this should be obvious. I’m killing myself and wearing out
google and I still don’t have a clue of what to do about this problem.
I have Apache 2.0.55 httpd.conf set up to use mod_rewrite to proxy requests to
mongrel at http://localhost:3000. All is well. One page of our web app
uploads a file. The upload works just fine.
Yes, apache should handle all the encryption, decryption for your
traffic
before talking to Mongrel.
But now, alas, I try to upload a file. Attempting to upload a file gives me
a ‘bad content body’ error at line 981 of cgi.rb, in the read_multipart
method. If I change that method to write its input out to a log, I see that
$stdin looks very much like encrypted stuff and not at all like clear text.
Now, do your test again doing the SSL and Non-SSL uploads. When it’s
done,
take the contents of log/mongrel_debug/rails.log and post it to a
nopaste
site for me to look at. It’s possible that the headers are mangled
before
coming in but not sure why Apache wouldn’t fix it.
So now, after much not very fruitful head banging, I have a bunch of questions
and I’m hoping that someone can point me in a useful direction.
Should I have done something in the apache config to make ssl decrypt this
file before passing it on to mongrel?
No idea.
Should I have done something in ruby to decrypt this file?
Nope, it should come properly decrypted. Now, it’s possible that it’s
not
really encrypted but instead just encoded in something unfamiliar to
CGI.
Should I be using something like Pound out in front of everything to handle
the en/decryption?
If you can, see if Pound has the same problem. If you can point Pound
at
Mongrel and the file upload works fine, then you just need to fix
apache.
If it still fails then something’s up with mongrel.
Ideas ?
