Mongrel 1.1

Server Mongrel
1

Hello Mongrels,

Mongrel 1.1 is out with fullblown JRuby support, some reorganization,
and some bugfixes. Also, Mongrel_cluster has been updated to 1.0.4.

Go subscribe to the all-new news feed, because we probably won’t
announce to the list anymore:

http://mongrel.rubyforge.org/rss.xml

Thanks

Evan, and the Mongrel Team

2

Ah, that explains why I didn’t know about 1.0.2 or 1.0.3 until 1.0.4
came out. Thanks for the clarification. :slight_smile:

On 11/1/07, Evan W. [email protected] wrote:

Thanks

–
Cheers,

Kevin W.
http://kevwil.com/

http://kevwil.jaiku.com/

3

I’m curious to know why the URL classifier was moved from C code to
Ruby code. I am under the impression that Ruby code is often much
slower than C extensions. I’m also under the impression that the URL
classifier is somewhere that speed would be desirable.

Please tell me if my impressions are based on false premises…

==
Will G.

4

On Thu Nov 01, 2007 at 11:06:16AM -0400, [email protected] wrote:

I’m curious to know why the URL classifier was moved from C code to
Ruby code.

really? my database dependson the performance of the C version of the
URL classifier

perhaps you told rubygems to install a pure ruby version instead of a
ruby+C version? er no, the ‘ruby’ in rubygems usually means posix (and
ruby+C) while ‘win32’ means what it says

5

On 11/1/07, [email protected] [email protected] wrote:

I’m curious to know why the URL classifier was moved from C code to
Ruby code. I am under the impression that Ruby code is often much
slower than C extensions. I’m also under the impression that the URL
classifier is somewhere that speed would be desirable.

C code will generally be faster than Ruby code, yes.

The thing with the classifier is that for small numbers of urls to
classify, the pure ruby solution is as fast or faster than the trie
based C classifier, and the decision was made that the simplification
represented by switching to a pure ruby solution there was a
beneficial tradeoff, since most people do not have more than a dozen
handlers registered with a mongrel instance, so for most people there
will be no performance loss.

Kirk H.

6

On 11/1/07, [email protected] [email protected] wrote:

7

Ah, well that makes sense!

Thanks for clearing that up!

Quoting Kirk H. [email protected]:

8

The pure Ruby classifier is faster than the C classifier in the
pathological case of only one handler (most Rails apps). They both
scale linearly up to about 14 urls, at which point the C classifier
performance curve goes flat. Hardly anybody uses that many handlers,
so we dumped the 450 line Trie and C classifier for 30-odd lines of
Ruby. This makes JRuby support much easier.

But seriously, even 8ish urls, the performance penalty per request for
the Ruby classifier is about 5 microseconds per request on a Mac Mini.
When your app is returning requests in the 100 microsecond range, then
maybe you should start to care; until then, no.

The C classifier is still available in the mongrel_experimental gem;
if you install it, it will automatically be used.

Evan

9

You still have to keep in mind that there is overhead to calling native
code. For small methods that don’t do much it is often better to write
the
code in the script language rather than suffer the overhead of a native
method call.

Rather than judging the ruby version bad, upgrade and profile to see if
there is a performance issue.