TUNING

   1 = Tuning Unicorn
   2
   3 Unicorn performance is generally as good as a (mostly) Ruby web server
   4 can provide.  Most often the performance bottleneck is in the web
   5 application running on Unicorn rather than Unicorn itself.
   6
   7 == Unicorn Configuration
   8
   9 See Unicorn::Configurator for details on the config file format.
  10
  11 * Setting a very low value for the :backlog parameter in "listen"
  12   directives can allow failover to happen more quickly if your
  13   cluster is configured for it.
  14
  15 * :rcvbuf and :sndbuf parameters generally do not need to be set for TCP
  16   listeners under Linux 2.6 because auto-tuning is enabled.  UNIX domain
  17   sockets do not have auto-tuning buffer sizes; so increasing those will
  18   allow syscalls and task switches to be saved for larger requests
  19   and responses.
  20
  21 * Setting "preload_app true" can allow copy-on-write-friendly GC to
  22   be used to save memory.  It will probably not work out of the box with
  23   applications that open sockets or perform random I/O on files.
  24   Databases like TokyoCabinet use concurrency-safe pread()/pwrite()
  25   functions for safe sharing of database file descriptors across
  26   processes.
  27
  28 * On POSIX-compliant filesystems, it is safe for multiple threads or
  29   processes to append to one log file as long as all the processes are
  30   have them unbuffered (File#sync = true) or they are
  31   record(line)-buffered in userspace.
  32
  33 * worker_processes should be scaled to the number of processes your
  34   backend system(s) can support.  DO NOT scale it to the number of
  35   external network clients your application expects to be serving.
  36   Unicorn is NOT for serving slow clients, that is the job of nginx.
  37
  38 == Kernel Parameters (Linux sysctl)
  39
  40 WARNING: Do not change system parameters unless you know what you're doing!
  41
  42 * net.core.rmem_max and net.core.wmem_max can increase the allowed
  43   size of :rcvbuf and :sndbuf respectively. This is mostly only useful
  44   for UNIX domain sockets which do not have auto-tuning buffer sizes.
  45
  46 * For load testing/benchmarking with UNIX domain sockets, you should
  47   consider increasing net.core.somaxconn or else nginx will start
  48   failing to connect under heavy load.
  49
  50 * If you're running out of local ports, consider lowering
  51   net.ipv4.tcp_fin_timeout to 20-30 (default: 60 seconds).  Also
  52   consider widening the usable port range by changing
  53   net.ipv4.ip_local_port_range.
  54
  55 * Setting net.ipv4.tcp_timestamps=1 will also allow setting
  56   net.ipv4.tcp_tw_reuse=1 and net.ipv4.tcp_tw_recycle=1, which along
  57   with the above settings can slow down port exhaustion.  Not all
  58   networks are compatible with these settings, check with your friendly
  59   network administrator before changing these.
  60
  61 * Increasing the MTU size can reduce framing overhead for larger
  62   transfers.  One often-overlooked detail is that the loopback
  63   device (usually "lo") can have its MTU increased, too.