unicorn-simon 0.0.1

data/PHILOSOPHY

@@ -0,0 +1,139 @@
+= The Philosophy Behind unicorn
+
+Being a server that only runs on Unix-like platforms, unicorn is
+strongly tied to the Unix philosophy of doing one thing and (hopefully)
+doing it well.  Despite using HTTP, unicorn is strictly a _backend_
+application server for running Rack-based Ruby applications.
+
+== Avoid Complexity
+
+Instead of attempting to be efficient at serving slow clients, unicorn
+relies on a buffering reverse proxy to efficiently deal with slow
+clients.
+
+unicorn uses an old-fashioned preforking worker model with blocking I/O.
+Our processing model is the antithesis of more modern (and theoretically
+more efficient) server processing models using threads or non-blocking
+I/O with events.
+
+=== Threads and Events Are Hard
+
+...to many developers.  Reasons for this is beyond the scope of this
+document.  unicorn avoids concurrency within each worker process so you
+have fewer things to worry about when developing your application.  Of
+course unicorn can use multiple worker processes to utilize multiple
+CPUs or spindles.  Applications can still use threads internally, however.
+
+== Slow Clients Are Problematic
+
+Most benchmarks we've seen don't tell you this, and unicorn doesn't
+care about slow clients... but <i>you</i> should.
+
+A "slow client" can be any client outside of your datacenter.  Network
+traffic within a local network is always faster than traffic that
+crosses outside of it.  The laws of physics do not allow otherwise.
+
+Persistent connections were introduced in HTTP/1.1 reduce latency from
+connection establishment and TCP slow start.  They also waste server
+resources when clients are idle.
+
+Persistent connections mean one of the unicorn worker processes
+(depending on your application, it can be very memory hungry) would
+spend a significant amount of its time idle keeping the connection alive
+<i>and not doing anything else</i>.  Being single-threaded and using
+blocking I/O, a worker cannot serve other clients while keeping a
+connection alive.  Thus unicorn does not implement persistent
+connections.
+
+If your application responses are larger than the socket buffer or if
+you're handling large requests (uploads), worker processes will also be
+bottlenecked by the speed of the *client* connection.  You should
+not allow unicorn to serve clients outside of your local network.
+
+== Application Concurrency != Network Concurrency
+
+Performance is asymmetric across the different subsystems of the machine
+and parts of the network.  CPUs and main memory can process gigabytes of
+data in a second; clients on the Internet are usually only capable of a
+tiny fraction of that.  unicorn deployments should avoid dealing with
+slow clients directly and instead rely on a reverse proxy to shield it
+from the effects of slow I/O.
+
+== Improved Performance Through Reverse Proxying
+
+By acting as a buffer to shield unicorn from slow I/O, a reverse proxy
+will inevitably incur overhead in the form of extra data copies.
+However, as I/O within a local network is fast (and faster still
+with local sockets), this overhead is negligible for the vast majority
+of HTTP requests and responses.
+
+The ideal reverse proxy complements the weaknesses of unicorn.
+A reverse proxy for unicorn should meet the following requirements:
+
+1. It should fully buffer all HTTP requests (and large responses).
+   Each request should be "corked" in the reverse proxy and sent
+   as fast as possible to the backend unicorn processes.  This is
+   the most important feature to look for when choosing a
+   reverse proxy for unicorn.
+
+2. It should spend minimal time in userspace.  Network (and disk) I/O
+   are system-level tasks and usually managed by the kernel.
+   This may change if userspace TCP stacks become more popular in the
+   future; but the reverse proxy should not waste time with
+   application-level logic.  These concerns should be separated
+
+3. It should avoid context switches and CPU scheduling overhead.
+   In many (most?) cases, network devices and their interrupts are
+   only be handled by one CPU at a time.  It should avoid contention
+   within the system by serializing all network I/O into one (or few)
+   userspace processes.  Network I/O is not a CPU-intensive task and
+   it is not helpful to use multiple CPU cores (at least not for GigE).
+
+4. It should efficiently manage persistent connections (and
+   pipelining) to slow clients.  If you care to serve slow clients
+   outside your network, then these features of HTTP/1.1 will help.
+
+5. It should (optionally) serve static files.  If you have static
+   files on your site (especially large ones), they are far more
+   efficiently served with as few data copies as possible (e.g. with
+   sendfile() to completely avoid copying the data to userspace).
+
+nginx is the only (Free) solution we know of that meets the above
+requirements.
+
+Indeed, the folks behind unicorn have deployed nginx as a reverse-proxy not
+only for Ruby applications, but also for production applications running
+Apache/mod_perl, Apache/mod_php and Apache Tomcat.  In every single
+case, performance improved because application servers were able to use
+backend resources more efficiently and spend less time waiting on slow
+I/O.
+
+== Worse Is Better
+
+Requirements and scope for applications change frequently and
+drastically.  Thus languages like Ruby and frameworks like Rails were
+built to give developers fewer things to worry about in the face of
+rapid change.
+
+On the other hand, stable protocols which host your applications (HTTP
+and TCP) only change rarely.  This is why we recommend you NOT tie your
+rapidly-changing application logic directly into the processes that deal
+with the stable outside world.  Instead, use HTTP as a common RPC
+protocol to communicate between your frontend and backend.
+
+In short: separate your concerns.
+
+Of course a theoretical "perfect" solution would combine the pieces
+and _maybe_ give you better performance at the end of the day, but
+that is not the Unix way.
+
+== Just Worse in Some Cases
+
+unicorn is not suited for all applications.  unicorn is optimized for
+applications that are CPU/memory/disk intensive and spend little time
+waiting on external resources (e.g. a database server or external API).
+
+unicorn is highly inefficient for Comet/reverse-HTTP/push applications
+where the HTTP connection spends a large amount of time idle.
+Nevertheless, the ease of troubleshooting, debugging, and management of
+unicorn may still outweigh the drawbacks for these applications.

data/README

@@ -0,0 +1,138 @@
+= unicorn: Rack HTTP server for fast clients and Unix
+
+unicorn is an HTTP server for Rack applications designed to only serve
+fast clients on low-latency, high-bandwidth connections and take
+advantage of features in Unix/Unix-like kernels.  Slow clients should
+only be served by placing a reverse proxy capable of fully buffering
+both the the request and response in between unicorn and slow clients.
+
+== Features
+
+* Designed for Rack, Unix, fast clients, and ease-of-debugging.  We
+  cut out everything that is better supported by the operating system,
+  {nginx}[http://nginx.org/] or {Rack}[http://rack.github.io/].
+
+* Compatible with Ruby 1.9.3 and later.
+  unicorn 4.x remains supported for Ruby 1.8 users.
+
+* Process management: unicorn will reap and restart workers that
+  die from broken apps.  There is no need to manage multiple processes
+  or ports yourself.  unicorn can spawn and manage any number of
+  worker processes you choose to scale to your backend.
+
+* Load balancing is done entirely by the operating system kernel.
+  Requests never pile up behind a busy worker process.
+
+* Does not care if your application is thread-safe or not, workers
+  all run within their own isolated address space and only serve one
+  client at a time for maximum robustness.
+
+* Builtin reopening of all log files in your application via
+  USR1 signal.  This allows logrotate to rotate files atomically and
+  quickly via rename instead of the racy and slow copytruncate method.
+  unicorn also takes steps to ensure multi-line log entries from one
+  request all stay within the same file.
+
+* nginx-style binary upgrades without losing connections.
+  You can upgrade unicorn, your entire application, libraries
+  and even your Ruby interpreter without dropping clients.
+
+* before_fork and after_fork hooks in case your application
+  has special needs when dealing with forked processes.  These
+  should not be needed when the "preload_app" directive is
+  false (the default).
+
+* Can be used with copy-on-write-friendly memory management
+  to save memory (by setting "preload_app" to true).
+
+* Able to listen on multiple interfaces including UNIX sockets,
+  each worker process can also bind to a private port via the
+  after_fork hook for easy debugging.
+
+* Simple and easy Ruby DSL for configuration.
+
+* Decodes chunked requests on-the-fly.
+
+== License
+
+unicorn is copyright 2009-2016 by all contributors (see logs in git).
+It is based on Mongrel 1.1.5.
+Mongrel is copyright 2007 Zed A. Shaw and contributors.
+
+unicorn is licensed under (your choice) of the GPLv2 or later
+(GPLv3+ preferred), or Ruby (1.8)-specific terms.
+See the included LICENSE file for details.
+
+unicorn is 100% Free Software (including all development tools used).
+
+== Install
+
+The library consists of a C extension so you'll need a C compiler
+and Ruby development libraries/headers.
+
+You may install it via RubyGems on RubyGems.org:
+
+  gem install unicorn
+
+You can get the latest source via git from the following locations
+(these versions may not be stable):
+
+  git://bogomips.org/unicorn.git
+  git://repo.or.cz/unicorn.git (mirror)
+
+You may browse the code from the web:
+
+* https://bogomips.org/unicorn.git
+* http://repo.or.cz/w/unicorn.git (gitweb)
+
+See the HACKING guide on how to contribute and build prerelease gems
+from git.
+
+== Usage
+
+=== Rack (including Rails 3+) applications
+
+In APP_ROOT, run:
+
+  unicorn
+
+unicorn will bind to all interfaces on TCP port 8080 by default.
+You may use the +--listen/-l+ switch to bind to a different
+address:port or a UNIX socket.
+
+=== Configuration File(s)
+
+unicorn will look for the config.ru file used by rackup in APP_ROOT.
+
+For deployments, it can use a config file for unicorn-specific options
+specified by the +--config-file/-c+ command-line switch.  See
+Unicorn::Configurator for the syntax of the unicorn-specific options.
+The default settings are designed for maximum out-of-the-box
+compatibility with existing applications.
+
+Most command-line options for other Rack applications (above) are also
+supported.  Run `unicorn -h` to see command-line options.
+
+== Disclaimer
+
+There is NO WARRANTY whatsoever if anything goes wrong, but
+{let us know}[link:ISSUES.html] and we'll try our best to fix it.
+
+unicorn is designed to only serve fast clients either on the local host
+or a fast LAN.  See the PHILOSOPHY and DESIGN documents for more details
+regarding this.
+
+== Contact
+
+All feedback (bug reports, user/development dicussion, patches, pull
+requests) go to the mailing list/newsgroup.  See the ISSUES document for
+information on the {mailing list}[mailto:unicorn-public@bogomips.org].
+
+The mailing list is archived at https://bogomips.org/unicorn-public/
+Read-only NNTP access is available at:
+nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn and
+nntp://news.gmane.org/gmane.comp.lang.ruby.unicorn.general
+
+For the latest on unicorn releases, you may also finger us at
+unicorn@bogomips.org or check our NEWS page (and subscribe to our Atom
+feed).

data/Rakefile

@@ -0,0 +1,16 @@
+# optional rake-compiler support in case somebody needs to cross compile
+begin
+  mk = "ext/unicorn_http/Makefile"
+  if File.readable?(mk)
+    warn "run 'gmake -C ext/unicorn_http clean' and\n" \
+         "remove #{mk} before using rake-compiler"
+  elsif ENV['VERSION']
+    unless File.readable?("ext/unicorn_http/unicorn_http.c")
+      abort "run 'gmake ragel' or 'make ragel' to generate the Ragel source"
+    end
+    spec = Gem::Specification.load('unicorn.gemspec')
+    require 'rake/extensiontask'
+    Rake::ExtensionTask.new('unicorn_http', spec)
+  end
+rescue LoadError
+end

data/SIGNALS

@@ -0,0 +1,123 @@
+== Signal handling
+
+In general, signals need only be sent to the master process.  However,
+the signals Unicorn uses internally to communicate with the worker
+processes are documented here as well.  With the exception of TTIN/TTOU,
+signal handling matches the behavior of {nginx}[http://nginx.org/] so it
+should be possible to easily share process management scripts between
+Unicorn and nginx.
+
+One example init script is distributed with unicorn:
+https://bogomips.org/unicorn/examples/init.sh
+
+=== Master Process
+
+* HUP - reloads config file and gracefully restart all workers.
+  If the "preload_app" directive is false (the default), then workers
+  will also pick up any application code changes when restarted.  If
+  "preload_app" is true, then application code changes will have no
+  effect; USR2 + QUIT (see below) must be used to load newer code in
+  this case.  When reloading the application, +Gem.refresh+ will
+  be called so updated code for your application can pick up newly
+  installed RubyGems.  It is not recommended that you uninstall
+  libraries your application depends on while Unicorn is running,
+  as respawned workers may enter a spawn loop when they fail to
+  load an uninstalled dependency.
+
+* INT/TERM - quick shutdown, kills all workers immediately
+
+* QUIT - graceful shutdown, waits for workers to finish their
+  current request before finishing.
+
+* USR1 - reopen all logs owned by the master and all workers
+  See Unicorn::Util.reopen_logs for what is considered a log.
+
+* USR2 - reexecute the running binary.  A separate QUIT
+  should be sent to the original process once the child is verified to
+  be up and running.
+
+* WINCH - gracefully stops workers but keep the master running.
+  This will only work for daemonized processes.
+
+* TTIN - increment the number of worker processes by one
+
+* TTOU - decrement the number of worker processes by one
+
+=== Worker Processes
+
+Note: as of unicorn 4.8, the master uses a pipe to signal workers
+instead of kill(2) for most cases.  Using signals still (and works and
+remains supported for external tools/libraries), however.
+
+Sending signals directly to the worker processes should not normally be
+needed.  If the master process is running, any exited worker will be
+automatically respawned.
+
+* INT/TERM - Quick shutdown, immediately exit.
+  Unless WINCH has been sent to the master (or the master is killed),
+  the master process will respawn a worker to replace this one.
+  Immediate shutdown is still triggered using kill(2) and not the
+  internal pipe as of unicorn 4.8
+
+* QUIT - Gracefully exit after finishing the current request.
+  Unless WINCH has been sent to the master (or the master is killed),
+  the master process will respawn a worker to replace this one.
+
+* USR1 - Reopen all logs owned by the worker process.
+  See Unicorn::Util.reopen_logs for what is considered a log.
+  Log files are not reopened until it is done processing
+  the current request, so multiple log lines for one request
+  (as done by Rails) will not be split across multiple logs.
+
+  It is NOT recommended to send the USR1 signal directly to workers via
+  "killall -USR1 unicorn" if you are using user/group-switching support
+  in your workers.  You will encounter incorrect file permissions and
+  workers will need to be respawned.  Sending USR1 to the master process
+  first will ensure logs have the correct permissions before the master
+  forwards the USR1 signal to workers.
+
+=== Procedure to replace a running unicorn executable
+
+You may replace a running instance of unicorn with a new one without
+losing any incoming connections.  Doing so will reload all of your
+application code, Unicorn config, Ruby executable, and all libraries.
+The only things that will not change (due to OS limitations) are:
+
+1. The path to the unicorn executable script.  If you want to change to
+   a different installation of Ruby, you can modify the shebang
+   line to point to your alternative interpreter.
+
+The procedure is exactly like that of nginx:
+
+1. Send USR2 to the master process
+
+2. Check your process manager or pid files to see if a new master spawned
+   successfully.  If you're using a pid file, the old process will have
+   ".oldbin" appended to its path.  You should have two master instances
+   of unicorn running now, both of which will have workers servicing
+   requests.  Your process tree should look something like this:
+
+     unicorn master (old)
+     \_ unicorn worker[0]
+     \_ unicorn worker[1]
+     \_ unicorn worker[2]
+     \_ unicorn worker[3]
+     \_ unicorn master
+        \_ unicorn worker[0]
+        \_ unicorn worker[1]
+        \_ unicorn worker[2]
+        \_ unicorn worker[3]
+
+3. You can now send WINCH to the old master process so only the new workers
+   serve requests.  If your unicorn process is bound to an interactive
+   terminal (not daemonized), you can skip this step.  Step 5 will be more
+   difficult but you can also skip it if your process is not daemonized.
+
+4. You should now ensure that everything is running correctly with the
+   new workers as the old workers die off.
+
+5. If everything seems ok, then send QUIT to the old master.  You're done!
+
+   If something is broken, then send HUP to the old master to reload
+   the config and restart its workers.  Then send QUIT to the new master
+   process.

data/Sandbox

@@ -0,0 +1,104 @@
+= Tips for using unicorn with Sandbox installation tools
+
+Since unicorn includes executables and is usually used to start a Ruby
+process, there are certain caveats to using it with tools that sandbox
+RubyGems installations such as
+{Bundler}[http://bundler.io/] or
+{Isolate}[https://github.com/jbarnette/isolate].
+
+== General deployment
+
+If you're sandboxing your unicorn installation and using Capistrano (or
+similar), it's required that you sandbox your RubyGems in a per-application
+shared directory that can be used between different revisions.
+
+unicorn will stash its original command-line at startup for the USR2
+upgrades, and cleaning up old revisions will cause revision-specific
+installations of unicorn to go missing and upgrades to fail.   If you
+find yourself in this situation and can't afford downtime, you can
+override the existing unicorn executable path in the config file like
+this:
+
+        Unicorn::HttpServer::START_CTX[0] = "/some/path/to/bin/unicorn"
+
+Then use HUP to reload, and then continue with the USR2+QUIT upgrade
+sequence.
+
+Environment variable pollution when exec-ing a new process (with USR2)
+is the primary issue with sandboxing tools such as Bundler and Isolate.
+
+== Bundler
+
+=== Running
+
+If you're bundling unicorn, use "bundle exec unicorn" (or "bundle exec
+unicorn_rails") to start unicorn with the correct environment variables
+
+ref: https://bogomips.org/unicorn-public/9ECF07C4-5216-47BE-961D-AFC0F0C82060@internetfamo.us/
+
+Otherwise (if you choose to not sandbox your unicorn installation), we
+expect the tips for Isolate (below) apply, too.
+
+=== RUBYOPT pollution from SIGUSR2 upgrades
+
+This is no longer be an issue as of bundler 0.9.17
+
+ref:
+https://bogomips.org/unicorn-public/8FC34B23-5994-41CC-B5AF-7198EF06909E@tramchase.com/
+
+=== BUNDLE_GEMFILE for Capistrano users
+
+You may need to set or reset the BUNDLE_GEMFILE environment variable in
+the before_exec hook:
+
+        before_exec do |server|
+          ENV["BUNDLE_GEMFILE"] = "/path/to/app/current/Gemfile"
+        end
+
+=== Other ENV pollution issues
+
+If you're using an older Bundler version (0.9.x), you may need to set or
+reset GEM_HOME, GEM_PATH and PATH environment variables in the
+before_exec hook as illustrated by https://gist.github.com/534668
+
+=== Ruby 2.0.0 close-on-exec and SIGUSR2 incompatibility
+
+Ruby 2.0.0 enforces FD_CLOEXEC on file descriptors by default.  unicorn
+has been prepared for this behavior since unicorn 4.1.0, and bundler
+needs the "--keep-file-descriptors" option for "bundle exec":
+http://bundler.io/man/bundle-exec.1.html
+
+== Isolate
+
+=== Running
+
+Installing "unicorn" as a system-wide Rubygem and using the
+isolate gem may cause issues if you're using any of the bundled
+application-level libraries in unicorn/app/* (for compatibility
+with CGI-based applications, Rails <= 2.2.2, or ExecCgi).
+For now workarounds include doing one of the following:
+
+1. Isolating unicorn, setting GEM_HOME to your Isolate path,
+   and running the isolated version of unicorn.  You *must* set
+   GEM_HOME before running your isolated unicorn install in this way.
+
+2.  Installing the same version of unicorn as a system-wide Rubygem
+    *and* isolating unicorn as well.
+
+3. Explicitly setting RUBYLIB or $LOAD_PATH to include any gem path
+   where the unicorn gem is installed
+   (e.g. /usr/lib/ruby/gems/1.9.3/gems/unicorn-VERSION/lib)
+
+=== RUBYOPT pollution from SIGUSR2 upgrades
+
+If you are using Isolate, using Isolate 2.x is strongly recommended as
+environment modifications are idempotent.
+
+If you are stuck with 1.x versions of Isolate, it is recommended that
+you disable it with the <tt>before_exec</tt> hook prevent the PATH and
+RUBYOPT environment variable modifications from propagating between
+upgrades in your Unicorn config file:
+
+        before_exec do |server|
+          Isolate.disable
+        end

data/TODO

@@ -0,0 +1,3 @@
+* Documentation improvements
+
+* improve test suite

data/TUNING

@@ -0,0 +1,119 @@
+= Tuning unicorn
+
+unicorn performance is generally as good as a (mostly) Ruby web server
+can provide.  Most often the performance bottleneck is in the web
+application running on Unicorn rather than Unicorn itself.
+
+== unicorn Configuration
+
+See Unicorn::Configurator for details on the config file format.
++worker_processes+ is the most-commonly needed tuning parameter.
+
+=== Unicorn::Configurator#worker_processes
+
+* worker_processes should be scaled to the number of processes your
+  backend system(s) can support.  DO NOT scale it to the number of
+  external network clients your application expects to be serving.
+  unicorn is NOT for serving slow clients, that is the job of nginx.
+
+* worker_processes should be *at* *least* the number of CPU cores on
+  a dedicated server (unless you do not have enough memory).
+  If your application has occasionally slow responses that are /not/
+  CPU-intensive, you may increase this to workaround those inefficiencies.
+
+* Under Ruby 2.2 or later, Etc.nprocessors may be used to determine
+  the number of CPU cores present.
+
+* worker_processes may be increased for Unicorn::OobGC users to provide
+  more consistent response times.
+
+* Never, ever, increase worker_processes to the point where the system
+  runs out of physical memory and hits swap.  Production servers should
+  never see heavy swap activity.
+
+=== Unicorn::Configurator#listen Options
+
+* Setting a very low value for the :backlog parameter in "listen"
+  directives can allow failover to happen more quickly if your
+  cluster is configured for it.
+
+* If you're doing extremely simple benchmarks and getting connection
+  errors under high request rates, increasing your :backlog parameter
+  above the already-generous default of 1024 can help avoid connection
+  errors.  Keep in mind this is not recommended for real traffic if
+  you have another machine to failover to (see above).
+
+* :rcvbuf and :sndbuf parameters generally do not need to be set for TCP
+  listeners under Linux 2.6 because auto-tuning is enabled.  UNIX domain
+  sockets do not have auto-tuning buffer sizes; so increasing those will
+  allow syscalls and task switches to be saved for larger requests
+  and responses.  If your app only generates small responses or expects
+  small requests, you may shrink the buffer sizes to save memory, too.
+
+* Having socket buffers too large can also be detrimental or have
+  little effect.  Huge buffers can put more pressure on the allocator
+  and may also thrash CPU caches, cancelling out performance gains
+  one would normally expect.
+
+* UNIX domain sockets are slightly faster than TCP sockets, but only
+  work if nginx is on the same machine.
+
+== Other unicorn settings
+
+* Setting "preload_app true" can allow copy-on-write-friendly GC to
+  be used to save memory.  It will probably not work out of the box with
+  applications that open sockets or perform random I/O on files.
+  Databases like TokyoCabinet use concurrency-safe pread()/pwrite()
+  functions for safe sharing of database file descriptors across
+  processes.
+
+* On POSIX-compliant filesystems, it is safe for multiple threads or
+  processes to append to one log file as long as all the processes are
+  have them unbuffered (File#sync = true) or they are
+  record(line)-buffered in userspace before any writes.
+
+== Kernel Parameters (Linux sysctl and sysfs)
+
+WARNING: Do not change system parameters unless you know what you're doing!
+
+* Transparent hugepages (THP) improves performance in many cases,
+  but can also increase memory use when relying on a
+  copy-on-write(CoW)-friendly GC (Ruby 2.0+) with "preload_app true".
+  CoW operates at the page level, so writing to a huge page would
+  trigger a 2 MB copy (x86-64), as opposed to a 4 KB copy on a
+  regular (non-huge) page.
+
+  Consider only allowing THP to be used when it is requested via the
+  madvise(2) syscall:
+
+	echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
+
+  Or disabling it system-wide, via "never".
+
+  n.b. "page" in this context only applies to the OS kernel,
+  Ruby GC implementations also use this term for the same concept
+  in a way that is agnostic to the OS.
+
+* net.core.rmem_max and net.core.wmem_max can increase the allowed
+  size of :rcvbuf and :sndbuf respectively. This is mostly only useful
+  for UNIX domain sockets which do not have auto-tuning buffer sizes.
+
+* For load testing/benchmarking with UNIX domain sockets, you should
+  consider increasing net.core.somaxconn or else nginx will start
+  failing to connect under heavy load.  You may also consider setting
+  a higher :backlog to listen on as noted earlier.
+
+* If you're running out of local ports, consider lowering
+  net.ipv4.tcp_fin_timeout to 20-30 (default: 60 seconds).  Also
+  consider widening the usable port range by changing
+  net.ipv4.ip_local_port_range.
+
+* Setting net.ipv4.tcp_timestamps=1 will also allow setting
+  net.ipv4.tcp_tw_reuse=1 and net.ipv4.tcp_tw_recycle=1, which along
+  with the above settings can slow down port exhaustion.  Not all
+  networks are compatible with these settings, check with your friendly
+  network administrator before changing these.
+
+* Increasing the MTU size can reduce framing overhead for larger
+  transfers.  One often-overlooked detail is that the loopback
+  device (usually "lo") can have its MTU increased, too.

data/archive/.gitignore

@@ -0,0 +1,3 @@
+/data
+/news
+/requests

data/archive/slrnpull.conf

@@ -0,0 +1,4 @@
+# group_name                         max        expire     headers_only
+gmane.comp.lang.ruby.unicorn.general 1000000000 1000000000 0
+
+# usage: slrnpull -d $PWD -h news.gmane.org --no-post