summary refs log tree commit homepage
path: root/TUNING
diff options
context:
space:
mode:
authorEric Wong <normalperson@yhbt.net>2009-10-19 10:20:34 -0700
committerEric Wong <normalperson@yhbt.net>2009-10-19 10:58:19 -0700
commiteba5b17340c24cf70e09f7d8fe381691e32feb9e (patch)
treee0bbfd834712b9902b34758e32d813dee8cdf5b5 /TUNING
parent9c5ce5b2f86591977727b7fdaa8fcc50aea089d6 (diff)
Diffstat (limited to 'TUNING')
-rw-r--r--TUNING14
1 files changed, 14 insertions, 0 deletions
diff --git a/TUNING b/TUNING
index 9f5f58d..a4d2498 100644
--- a/TUNING
+++ b/TUNING
@@ -7,6 +7,13 @@ of the time waiting on network activity.  Thus memory usage and memory
 bandwidth for keeping connections open are often limiting factors as
 well.
 
+As of October 2009, absolutely ZERO work has been done for performance
+validation and tuning.  Furthermore, \Rainbows! is NOT expected to do well on
+traditional benchmarks.  Remember that \Rainbows! is only designed for
+applications that sleep and/or trickle network traffic.  In the future,
+*may* do well in traditional benchmarks as a side effect, but that will
+never be the primary goal of the project.
+
 == \Rainbows! configuration
 
 * Don't set +worker_connections+ too high.  It is often better to start
@@ -18,6 +25,13 @@ well.
   robust against crashes and are more likely to be fairly scheduled by
   the kernel.
 
+* If your workers do not seem to be releasing memory to the OS after
+  traffic spikes, consider the {mall}[http://bogomips.org/mall/] library
+  which allows access to the mallopt(3) function from Ruby. As of
+  October 2009 tcmalloc (the default allocator for Ruby Enterprise
+  Edition) does not release memory back to the kernel, the best it can
+  do is use madvise(2) in an effort to swap out unused pages.
+
 == nginx configuration
 
 If you intend to use nginx as a reverse-proxy in front of \Rainbows!  to