From normalperson at yhbt.net  Sat Feb 13 05:39:18 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Sat, 13 Feb 2010 10:39:18 +0000
Subject: [ANN] Zbatery 0.1.1 - leak fix from Unicorn
In-Reply-To: <20100213103757.GB7833@dcvr.yhbt.net>
References: <20100213103409.GA7833@dcvr.yhbt.net>
	<20100213103757.GB7833@dcvr.yhbt.net>
Message-ID: <20100213103918.GC7833@dcvr.yhbt.net>

Unicorn had a memory leak that didn't affect Unicorn, but only
Rainbows!, so we bumped the dependency on Rainbows!  which in turn
bumped the dependency on Unicorn...

Also some minor documentation updates.

* http://zbatery.bogomip.org/
* rainbows-talk at rubyforge.org
* git://git.bogomips.org/zbatery.git

-- 
Eric Wong

From normalperson at yhbt.net  Sat Feb 13 05:34:09 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Sat, 13 Feb 2010 10:34:09 +0000
Subject: [ANN] unicorn 0.96.1 - leak fix for Rainbows!/Zbatery
Message-ID: <20100213103409.GA7833@dcvr.yhbt.net>

First off, this memory leak doesn't affect Unicorn itself at all
(but it doesn't hurt, either).

Unicorn itself always allocates the HttpParser once and always reuses it
in every sequential request.

This leak only affects applications that repeatedly allocate a new HTTP
parser.  Thus this bug affects _all_ deployments of Rainbows! and
Zbatery.  These servers allocate a new parser for every client
connection to serve clients concurrently, but due to a bug in Unicorn,
never allows the Ruby GC to properly free the memory allocated.

Here's what happened:

  I misread the Data_Make_Struct()/Data_Wrap_Struct()
  documentation and ended up passing NULL as the "free" argument
  instead of -1, causing the memory to never be freed.

  From README.EXT in the MRI source which I misread:
  > The free argument is the function to free the pointer
  > allocation.  If this is -1, the pointer will be just freed.
  > The functions mark and free will be called from garbage
  > collector.

Yes, I suck at reading and can't write code properly as a result.

* http://unicorn.bogomips.org/
* mongrel-unicorn at rubyforge.org
* git://git.bogomips.org/unicorn.git

-- 
Eric Wong

From normalperson at yhbt.net  Sat Feb 13 05:37:57 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Sat, 13 Feb 2010 10:37:57 +0000
Subject: [ANN] Rainbows! 0.90.2 - leak fix from Unicorn
In-Reply-To: <20100213103409.GA7833@dcvr.yhbt.net>
References: <20100213103409.GA7833@dcvr.yhbt.net>
Message-ID: <20100213103757.GB7833@dcvr.yhbt.net>

This release depends on Unicorn 0.96.1 for an updated
Unicorn::HttpParser to avoid leaking memory.

The HttpParser in Unicorn <= 0.96.0 did not setup the parser
object properly to be freed by the garbage collector.

While this bug did not affect Unicorn itself, Rainbows!
allocates a new Unicorn::HttpParser object for every new client
connection and Unicorn did not properly setup the parser object
to be freed by the Ruby garbage collector.

There are also minor cosmetic cleanups and fixes:

Eric Wong (10):
      http_response: disallow blank, multi-value headers
      Fix "rainbows -h" and "rainbows -v"
      Update docs + tests to reflect Rev 0.3.2 release
      local.mk.sample: bump Rack dependency
      Merge branch 'rack-1.1'
      add Cramp integration tests
      Rakefile: autoload Gem
      t/bin/*: encoding should be the first line after shebang
      gemspec: bump dependency on Unicorn to avoid leak
      Rainbows! 0.90.2

* http://rainbows.rubyforge.org/
* rainbows-talk at rubyforge.org
* git://git.bogomips.org/rainbows.git

-- 
Eric Wong

From normalperson at yhbt.net  Fri Feb 19 17:09:04 2010
From: normalperson at yhbt.net (Eric Wong)
Date: Fri, 19 Feb 2010 14:09:04 -0800
Subject: [RFD] keepalive_timeout default: 2s => 5s
Message-ID: <20100219220904.GA11377@dcvr.yhbt.net>

This is mostly only relevant to folks who run Rainbows! without a proxy
in front of it, which I suppose are few...

The current keepalive time is only 2s, which is enough for broadband
connections and even tiny HTTP responses on dialup, but not enough
for large responses to slow clients.

For HTTP keepalive, there needs to be enough time to load all inline
assets (images/frames/iframes/JS/CSS/AJAX) without an additional TCP
connection.

For larger responses on slow connections (say 4K/s), this means the last
chunk of the response is written into the kernel socket buffer and the
userspace process (Rainbows!) has no visibility into when the client
finishes receiving data.

With Linux 2.6 defaults (16K TCP send buffer) with 4K/s downstream to
the client, that's 4 seconds of transfer time a userspace process
(Rainbows!) can't account for at all.

With the 2s default keepalive, Rainbows! would've timed out the client
connection before the client has even had a chance to finish receiving
data.

So with a 5s keepalive, we still leave the client with 1 second to fully
parse the initial HTML page and send more requests upstream.  Some
clients (afaik) parse HTML and send additional requests while
downloading.

Using 6 seconds would give some more room to deal with latency and slow
clients for little additional cost.

For reference, Apache 2.2 uses 5 seconds as the default, too.

  http://httpd.apache.org/docs/2.2/mod/core.html#keepalivetimeout

Given that several of Rainbows! concurrency models are less overhead
per-connection than Apache threaded/prefork models, 5-6 seconds should
be a safe enough default for us.

-- 
Eric Wong