Rainbows! Rack HTTP server user/dev discussion
 help / color / mirror / code / Atom feed
blob 7686624fc095e62217ab47407662463dd5a7b974 2020 bytes (raw)
name: TUNING 	 # note: path name is non-authoritative(*)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
= Tuning \Rainbows!

Most of the {tuning notes}[https://yhbt.net/unicorn/TUNING.html]
apply to \Rainbows! as well.  \Rainbows! is not particularly optimized
at the moment and is designed for applications that spend large amounts
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
  denying requests and only serve the clients you can than to be
  completely bogged down and be unusable for everybody.

* Increase +worker_processes+ if you have resources (RAM/DB connections)
  available.  Additional worker processes can better utilize SMP, are more
  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}[https://yhbt.net/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
handle Comet applications, make sure you disable proxy response
buffering in nginx:

  proxy_buffering off;

This can be disabled on a per-backend basis in nginx, so under no
circumstances should you disable response buffering to Unicorn
backends, only to \Rainbows! backends.

debug log:

solving 7686624 ...
found 7686624 in https://yhbt.net/rainbows.git/

(*) Git path names are given by the tree(s) the blob belongs to.
    Blobs themselves have no identifier aside from the hash of its contents.^

Code repositories for project(s) associated with this public inbox

	https://yhbt.net/rainbows.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).