From: robbin <fankai@...>
Date: 2008-12-23T15:28:02+09:00
Subject: [ruby-core:20825] Re: [PATCH] Promising C coding techniques to reduce MRI's memory use


Hi, Brent:

   I have test MBARI patch on JavaEye.com (http://www.javaeye.com) , that is
a chinese software development community website which has 200,000 members
and 800,00 pageviews per day. JavaEye is written by Ruby on Rails and
running with lighttpd/fastcgi mode. The server environment: AMD64 machine,
SuSE Linux x86-64, ruby 1.8.7-p72 and Rails 2.1.2.

   I test Rails app performance and memory usage with 4 ruby implements: 

   1. ruby MRI  1.8.7-p72

   2. ruby 1.8.7-p72 with Railsbench GC patch and set GC variables below:
          RUBY_HEAP_MIN_SLOTS=600000
          RUBY_HEAP_SLOTS_INCREMENT=600000
          RUBY_HEAP_FREE_MIN=100000
          RUBY_GC_MALLOC_LIMIT=60000000
 
   3. ruby 1.8.7-p72 with MBARI patch.

   4. ruby 1.8.7-p72 with MBARI patch but I modified GC variables in gc.c
same as above.


   Test one: Simple Rails app

    I create a simple rails app to test rails routes and template rendering:

 ab -c 1 -n 1000 http://localhost:3000/test/index

ruby version                          performance      memory 
-----------------------------------------------------
ruby                                    106 request/s     39MB
ruby GC patch                       125 request/s     60MB
ruby MBARI patch                  160 request/s     35MB
ruby MBARI merge GC patch    173 request/s      60MB

 Test One Summary: MBARI patch save a little memory than MRI but improve
rails performance significantly.

   Test two: Real Rails website test
   
    I select two typical page on JavaEye.com to benchmark:

    Page 1 : http://robbin.javaeye.com/ 

ab -c 1 -n 100 http://robbin.joinnet.cn/

ruby version                 performance      memory 
-----------------------------------------------------
ruby                                  1.69 request/s    136MB
ruby GC patch                     2.81 request/s    179MB
ruby MBARI patch                1.96 request/s    103MB
ruby MBARI merge GC patch   2.90 request/s    158MB

     Page 2: http://robbin.joinnet.cn/blog/283992

ruby version                        performance      memory 
-----------------------------------------------------
ruby                                  2.20 request/s    136MB
ruby GC patch                     3.61 request/s    179MB
ruby MBARI patch                2.47 request/s    103MB
ruby MBARI merge GC patch  3.73 request/s    158MB

Test Two Summary: 

   1. MBARI patch not only save a lot of memory than MRI but also improve
rails performance about 13%
   2. MBARI merge with Railsbench GC patch win others with the highest rails
performance and save some memory than Railsbench GC patch.

 My suggest:

    1. MBARI patch has some uncompatible with complicated Regexp. for
example, I met this  error: premature end of regular expression: /0��k
\000\000\000\000x/  On line #12 of blog/index/_blog.rhtml

    2. I wish MBARI merge Railsbench GC patch, because Railsbench GC patch
has a lot of rails performance improvement on JavaEye.com website.

    3. I expect MBARI merge into ruby trunk :)



Brent Roman wrote:
> 
> I've finally put together the promised set of patches against version
> 1.8.7-p72 and posted them at:
> 
> http://sites.google.com/site/brentsrubypatches
> 
> From that page:
> 
> Aside from bug fixes, the primary goal of these patches is to reduce the
> memory consumption of the 1.8 series Ruby interpreters.  Happily, these
> same techniques tend also to increase the speed of most applications, but
> speed increase was not my primary concern. 
> 
> Each of the six patches below (mbari1-6) fixes a specific problem with or
> optimizes some facet of the Ruby interpreter.  The patches were intended
> to be applied in order, starting with official interpreter release
> 1.8.7-patchlevel72 from ruby-lang.org.  However, you may be able to apply
> only a subset of them if you don't want a particular feature or
> optimization.
> 
> Until more people test them, this must all be treated as alpha quality
> software. ...
> 
> My development environment today is 32-bit Intel x86 Linux compiling with
> gcc version 4.3.2.  I've tried to keep these patches portable to other
> platforms, but will make no such claims until others have tested them
> there.  If you test these under MS-Windows, I'll be interested and try to
> be helpful, but I won't be able to verify your results.
> 
> Please post any bugs, flames, benchmark results, requests for improvement,
> etc. to the ruby-core mailing list by replying to this message.
> 

-- 
View this message in context: http://www.nabble.com/-ruby-core%3A19846---Bug--744--memory-leak-in-callcc--tp20447794p21140287.html
Sent from the ruby-core mailing list archive at Nabble.com.