passenger 2.1.3 → 2.2.0

data/doc/Users guide Nginx.txt

@@ -0,0 +1,776 @@
+= Phusion Passenger users guide, Nginx version =
+
+image:images/phusion_banner.png[link="http://www.phusion.nl/"]
+
+Phusion Passenger is an Nginx module, which makes deploying Ruby and Ruby on
+Rails applications on Nginx a breeze. It follows the usual Ruby on Rails
+conventions, such as "Don't-Repeat-Yourself" and ease of setup, while at the
+same time providing enough flexibility.
+
+This users guide will teach you:
+
+- How to install Nginx with Phusion Passenger support.
+- How to configure Phusion Passenger.
+- How to deploy a Ruby on Rails application.
+- How to deploy a link:http://rack.rubyforge.org/[Rack]-based Ruby application.
+- How to solve common problems.
+
+This guide assumes that the reader is somewhat familiar with Nginx and with
+using the commandline.
+
+
+== Supported operating systems ==
+
+Phusion Passenger works on any POSIX-compliant operating system. In other
+words: practically any operating system on earth, except Microsoft Windows.
+
+Phusion Passenger for Nginx has been tested on:
+
+- Ubuntu Linux 8.04 (x86)
+- Gentoo Linux (AMD64)
+- MacOS X Leopard (x86)
+
+Other operating systems have not been tested, but Phusion Passenger will probably
+work fine on them. Please
+link:http://code.google.com/p/phusion-passenger/issues/list[report a bug]
+or
+link:http://groups.google.com/group/phusion-passenger[join our discussion list]
+if it doesn't.
+
+
+[[install_passenger]]
+== Installing Phusion Passenger ==
+
+=== Overview ===
+
+As you might already know, Nginx does not support loadable modules, in contrast
+to most other web servers (e.g. Apache). Therefore, to install Phusion Passenger
+for Nginx, one must recompile and reinstall Nginx with Phusion Passenger support.
+There are two ways to do this:
+
+1. By running the Phusion Passenger installer for Nginx. This installer will
+   guide you through the entire installation process, including downloading,
+   compiling and installing Nginx. You should be able to get Nginx with Phusion
+   Passenger support up-and-running in a matter of minutes. This is the
+   recommended installation method.
+2. By manually configuring and compiling Nginx with Phusion Passenger support,
+   through Nginx's `--add-module` configure option. Generally, using our
+   installer is easier, so you should only use this method if you're already
+   familiar with compiling Nginx.
+
+TIP: You might have to run the installation commands in the following sections
+as 'root'. If the installer fails because of permission errors, it will tell
+you.
+
+[[specifying_ruby_installation]]
+=== Specifying the correct Ruby installation ===
+
+If your system has multiple Ruby installations -- which is likely the case on
+MacOS X, or if you've also installed
+link:http://www.rubyenterpriseedition.com[Ruby Enterprise Edition] -- then you
+will need to tell the operating system which Ruby installation to use, prior to
+running the Phusion Passenger installer. If you only have one Ruby installation
+(the case on most Linux systems), then you can skip this section because Phusion
+Passenger will automatically detect it.
+
+To specify a Ruby installation, prepend your Ruby installation's `bin`
+directory to the `PATH` environment variable. For example, if you have the
+following Ruby installations:
+
+- /usr/bin/ruby
+- /opt/myruby/bin/ruby
+
+and you want to use the latter, then type:
+
+----------------------------------
+export PATH=/opt/myruby/bin:$PATH
+----------------------------------
+
+=== Installing Phusion Passenger for Nginx through the installer ===
+
+==== Obtaining the Phusion Passenger files and running the installer ====
+
+You must obtain the Phusion Passenger files in order to run the installer.
+This can be done either by installing the Phusion Passenger gem, or by
+downloading the source tarball.
+
+===== Gem =====
+
+First, install the Phusion Passenger gem by running:
+
+---------------------------------
+gem install passenger
+---------------------------------
+
+Next, run the Phusion Passenger installer for Nginx:
+
+---------------------------------
+passenger-install-nginx-module
+---------------------------------
+
+Please follow the instructions given by the installer.
+
+===== Source tarball =====
+
+The source tarball can be download from the
+link:http://www.modrails.com/[Phusion Passenger website]. Extract the tarball to
+whatever location you prefer. *The Phusion Passenger files are to reside in that
+location permanently.* For example, if you would like Phusion Passenger to
+reside in `/opt/passenger-x.x.x`, then type:
+
+--------------------------------------------------------------
+cd /opt
+tar xzvf ~/YourDownloadsFolder/passenger-x.x.x.tar.gz
+--------------------------------------------------------------
+
+Next, run the Phusion Passenger installer for Nginx:
+
+--------------------------------------------------------------
+/opt/passenger-x.x.x/bin/passenger-install-nginx-module
+--------------------------------------------------------------
+
+Please follow the instructions given by the installer.
+
+IMPORTANT: Please do not remove the passenger-x.x.x folder after installation.
+Furthermore, the passenger-x.x.x folder must be accessible by Nginx.
+
+==== Non-interactive/automatic installation ====
+
+By default, the installer is interactive. If you want to automate installation,
+then you can do so by passing various answers to the installer through command
+line options.
+
+Please run the installer with `--help` for a list of available command line
+options.
+
+=== Installing Phusion Passenger for Nginx manually ===
+
+You can also install Phusion Passenger the way you install any other Nginx module.
+To do this, run Nginx's configure script with `--add-module=/path-to-passenger-root/ext/nginx`.
+
+If you installed Phusion Passenger via the gem, then 'path-to-passenger-root'
+can be obtained with the command:
+
+--------------------------
+passenger-config --root
+--------------------------
+
+This will probably output something along the lines of '/usr/lib/ruby/gems/1.8/gems/passenger-x.x.x',
+so you'll probably have to specify something like `--add-module=/usr/lib/ruby/gems/1.8/gems/passenger-x.x.x/ext/nginx`.
+
+If you installed Phusion Passenger via a source tarball, then 'path-to-passenger-root'
+is the directory which contains the Phusion Passenger source code. So if you
+extracted the Phusion Passenger source code to '/opt/passenger-x.x.x', then you'll
+have to specify `--add-module=/opt/passenger-x.x.x/ext/nginx`.
+
+
+[[deploying_a_ror_app]]
+== Deploying a Ruby on Rails application ==
+
+Suppose you have a Ruby on Rails application in '/webapps/mycook', and you own
+the domain 'www.mycook.com'. You can either deploy your application to the
+virtual host's root (i.e. the application will be accessible from the root URL,
+'http://www.mycook.com/'), or in a sub URI (i.e. the application will be
+accessible from a sub URL, such as 'http://www.mycook.com/railsapplication').
+
+NOTE: The default `RAILS_ENV` environment in which deployed Rails applications
+are run, is ``production''. You can change this by changing the
+<<RailsEnv,rails_env>> configuration option.
+
+=== Deploying to a virtual host's root ===
+
+Add a 'server' virtual host entry to your Nginx configuration file. The virtual
+host's root must point to your Ruby on Rails application's 'public' folder.
+
+Inside the 'server' block, set 'passenger_enabled on'.
+
+For example:
+-------------------------------------------
+http {
+    ...
+    
+    server {
+        listen 80;
+        server_name www.mycook.com;
+        root /webapps/mycook/public;
+        passenger_enabled on;
+    }
+    
+    ...
+}
+-------------------------------------------
+Then restart Nginx. The application has now been deployed.
+
+[[deploying_rails_to_sub_uri]]
+=== Deploying to a sub URI ===
+
+Suppose that you already have a 'server' virtual host entry:
+
+-------------------------------------------
+http {
+    ...
+    
+    server {
+        listen 80;
+        server_name www.phusion.nl;
+        root /websites/phusion;
+    }
+    
+    ...
+}
+-------------------------------------------
+
+And you want your Ruby on Rails application to be accessible from the URL
+'http://www.phusion.nl/rails'.
+
+To do this, make a symlink from your Ruby on Rails application's 'public'
+folder to a directory in the document root. For example:
+-------------------------------------------
+ln -s /webapps/mycook/public /websites/phusion/rails
+-------------------------------------------
+
+Next, set 'passenger_enabled on' and add a <<PassengerBaseURI,passenger_base_uri>>
+option to the 'server' block:
+-------------------------------------------
+http {
+    ...
+    
+    server {
+        listen 80;
+        server_name www.phusion.nl;
+        root /websites/phusion;
+        passenger_enabled on;        # <--- These lines have
+        passenger_base_uri /rails;   # <--- been added.
+    }
+    
+    ...
+}
+-------------------------------------------
+Then restart Nginx. The application has now been deployed.
+
+[TIP]
+======================================
+You can deploy multiple Rails applications under a virtual host, by specifying
+<<PassengerBaseURI,passenger_base_uri>> multiple times. For example:
+---------------------------------
+server {
+    ...
+    passenger_base_uri /app1;
+    passenger_base_uri /app2;
+    passenger_base_uri /app3;
+}
+---------------------------------
+======================================
+
+=== Redeploying (restarting the Ruby on Rails application) ===
+
+Deploying a new version of a Ruby on Rails application is as simple as
+re-uploading the application files, and restarting the application.
+
+There are two ways to restart the application:
+
+1. By restarting Nginx.
+2. By creating or modifying the file 'tmp/restart.txt' in the Rails
+   application's <<application_root,root folder>>. Phusion Passenger will
+   automatically restart the application.
+
+For example, to restart our example MyCook application, we type this in the
+command line:
+-------------------------------------------
+touch /webapps/mycook/tmp/restart.txt
+-------------------------------------------
+
+=== Migrations ===
+
+Phusion Passenger is not related to Ruby on Rails migrations in any way. To
+run migrations on your deployment server, please login to your deployment
+server (e.g. with 'ssh') and type `rake db:migrate RAILS_ENV=production` in
+a shell console, just like one would normally run migrations.
+
+=== Capistrano integration ===
+
+See <<capistrano,Capistrano recipe>>.
+
+
+[[deploying_a_rack_app]]
+== Deploying a Rack-based Ruby application ==
+
+Phusion Passenger supports arbitrary Ruby web applications that follow the
+link:http://rack.rubyforge.org/[Rack] interface.
+
+Phusion Passenger assumes that Rack application directories have a certain layout.
+Suppose that you have a Rack application in '/webapps/rackapp'. Then that
+folder must contain at least three entries:
+
+- 'config.ru', a Rackup file for starting the Rack application. This file must contain
+  the complete logic for initializing the application.
+- 'public/', a folder containing public static web assets, like images and stylesheets.
+- 'tmp/', used for 'restart.txt' (our application restart mechanism). This will
+  be explained in a following subsection.
+
+So '/webapps/rackapp' must, at minimum, look like this:
+----------------------
+/webapps/rackapp
+  |
+  +-- config.ru
+  |
+  +-- public/
+  |
+  +-- tmp/
+----------------------
+
+Suppose you own the domain 'www.rackapp.com'. You can either deploy your application
+to the virtual host's root (i.e. the application will be accessible from the root URL,
+'http://www.rackapp.com/'), or in a sub URI (i.e. the application will be
+accessible from a sub URL, such as 'http://www.rackapp.com/rackapp').
+
+NOTE: The default `RACK_ENV` environment in which deployed Rack applications
+are run, is ``production''. You can change this by changing the
+<<RackEnv,rack_env>> configuration option.
+
+=== Tutorial/example: writing and deploying a Hello World Rack application ===
+
+First we create a Phusion Passenger-compliant Rack directory structure:
+
+-------------------------------------------
+$ mkdir /webapps/rack_example
+$ mkdir /webapps/rack_example/public
+$ mkdir /webapps/rack_example/tmp
+-------------------------------------------
+
+Next, we write a minimal "hello world" Rack application:
+
+-------------------------------------------
+$ cd /webapps/rack_example
+$ some_awesome_editor config.ru
+...type in some source code...
+$ cat config.ru
+app = proc do |env|
+    return [200, { "Content-Type" => "text/html" }, "hello <b>world</b>"]
+end
+run app
+-------------------------------------------
+
+Finally, we deploy it by adding the following configuration options to
+the Apache configuration file:
+
+-------------------------------------------
+http {
+    ...
+    server {
+        listen 80;
+        server_name www.rackexample.com;
+        root /webapps/rack_example/public;
+        passenger_enabled on;
+    }
+    ...
+}
+-------------------------------------------
+
+And we're done! After an Nginx restart, the above Rack application will be available
+under the URL 'http://www.rackexample.com/'.
+
+=== Deploying to a virtual host's root ===
+
+Add a 'server' virtual host entry to your Nginx configuration file. The virtual host's
+root must point to your Rack application's 'public' folder. You must also set
+'passenger_enabled on' in the 'server' block.
+
+For example:
+-------------------------------------------
+http {
+    ...
+    server {
+        listen 80;
+        server_name www.rackapp.com;
+        root /webapps/rackapp/public;
+        passenger_enabled on;
+    }
+    ...
+}
+-------------------------------------------
+Then restart Nginx. The application has now been deployed.
+
+[[deploying_rack_to_sub_uri]]
+=== Deploying to a sub URI ===
+
+Suppose that you already have a virtual host:
+
+-------------------------------------------
+http {
+    ...
+    
+    server {
+        listen 80;
+        server_name www.phusion.nl;
+        root /websites/phusion;
+        passenger_enabled on;
+    }
+    
+    ...
+}
+-------------------------------------------
+
+And you want your Rack application to be accessible from the URL
+'http://www.phusion.nl/rack'.
+
+To do this, make a symlink from your Rack application's 'public'
+folder to a directory in the document root. For example:
+-------------------------------------------
+ln -s /webapps/rackapp/public /websites/phusion/rack
+-------------------------------------------
+
+Next, set 'passenger_enabled on' and add a <<PassengerBaseURI,passenger_base_uri>>
+option to the 'server' block:
+-------------------------------------------
+http {
+    ...
+    
+    server {
+        listen 80;
+        server_name www.phusion.nl;
+        root /websites/phusion;
+        passenger_enabled on;        # <--- These lines have
+        passenger_base_uri /rack;    # <--- been added.
+    }
+    
+    ...
+}
+-------------------------------------------
+Then restart Apache. The application has now been deployed.
+
+[TIP]
+======================================
+You can deploy multiple Rack applications under a virtual host, by specifying
+<<PassengerBaseURI,passenger_base_uri>> multiple times. For example:
+---------------------------------
+server {
+    ...
+    passenger_base_uri /app1;
+    passenger_base_uri /app2;
+    passenger_base_uri /app3;
+}
+---------------------------------
+======================================
+
+=== Redeploying (restarting the Rack application) ===
+
+Deploying a new version of a Rack application is as simple as
+re-uploading the application files, and restarting the application.
+
+There are two ways to restart the application:
+
+1. By restarting Nginx.
+2. By creating or modifying the file 'tmp/restart.txt' in the Rack
+   application's <<application_root,root folder>>. Phusion Passenger will
+   automatically restart the application.
+
+For example, to restart our example application, we type this in the
+command line:
+-------------------------------------------
+touch /webapps/rackapp/tmp/restart.txt
+-------------------------------------------
+
+=== Rackup specifications for various web frameworks ===
+include::users_guide_snippets/rackup_specifications.txt[]
+
+
+== Configuring Phusion Passenger ==
+
+After installation, Phusion Passenger does not need any further configurations.
+Nevertheless, the system administrator may be interested in changing
+Phusion Passenger's behavior. Phusion Passenger supports the following configuration
+options in the Nginx configuration file:
+
+=== passenger_root <directory> ===
+The location to the Phusion Passenger root directory. This configuration option
+is essential to Phusion Passenger, and allows Phusion Passenger to locate its own
+data files. The correct value is given by the installer.
+
+If you've moved Phusion Passenger to a different directory then you need to update
+this option as well. Please read
+<<moving_phusion_passenger,Moving Phusion Passenger to a different directory>> for more information.
+
+This required option may only occur once, in the 'http' configuration block.
+
+=== passenger_log_level <integer> ===
+This option allows one to specify how much information Phusion Passenger should
+write to the Apache error log file. A higher log level value means that more
+information will be logged.
+
+Possible values are:
+
+- '0': Show only errors and warnings.
+- '1': Show the most important debugging information. This might be useful for
+       system administrators who are trying to figure out the cause of a
+       problem.
+- '2': Show more debugging information. This is typically only useful for developers.
+- '3': Show even more debugging information.
+
+This option may only occur once, in the 'http' configuration block.
+The default is '0'.
+
+=== passenger_ruby <filename> ===
+This option allows one to specify the Ruby interpreter to use.
+
+This option may only occur once, in the 'http' configuration block.
+The default is 'ruby'.
+
+[[PassengerUseGlobalQueue]]
+=== passenger_use_global_queue <on|off> ===
+Turns the use of global queuing on or off.
+
+This option may occur in the following places:
+
+ * In a 'server' configuration block.
+ * In a 'location' configuration block.
+ * In an 'if' configuration scope.
+
+In each place, it may be specified at most once. The default value is 'off'.
+
+'This feature is sponsored by http://www.37signals.com/[37signals].'
+
+include::users_guide_snippets/global_queueing_explained.txt[]
+
+[[PassengerUserSwitching]]
+=== passenger_user_switching <on|off> ===
+Whether to enable <<user_switching,user switching support>>.
+
+This option may only occur once, in the 'http' configuration block.
+The default value is 'on'.
+
+[[PassengerDefaultUser]]
+=== passenger_default_user <username> ===
+Phusion Passenger enables <<user_switching,user switching support>> by default.
+This configuration option allows one to specify which user Rails/Rack
+applications must run as, if user switching fails or is disabled.
+
+This option may only occur once, in the 'http' configuration block.
+The default value is 'nobody'.
+
+=== Important deployment options
+==== passenger_enabled <on|off> ====
+This option may be specified in a 'server' configuration block, a
+'location' configuration block or an 'if' configuration scope, to
+enable or disable Phusion Passenger for that server or that location.
+
+Phusion Passenger is disabled by default, so you must explicitly enable
+it for server blocks that you wish to serve through Phusion Passenger.
+Please see <<deploying_a_ror_app,Deploying a Ruby on Rails application>>
+and <<deploying_a_rack_app,Deploying a Rack-based Ruby application>>
+for examples.
+
+[[PassengerBaseURI]]
+==== passenger_base_uri <uri> ====
+Used to specify that the given URI is an distinct application that should
+be served by Phusion Passenger. This option can be used for both Rails and
+Rack applications. See <<deploying_rails_to_sub_uri,Deploying Rails to a sub URI>>
+for an example.
+
+It is allowed to specify this option multiple times. Do this to deploy multiple
+applications in different sub-URIs under the same virtual host.
+
+This option may occur in the following places:
+
+ * In a 'server' configuration block.
+ * In a 'location' configuration block.
+ * In an 'if' configuration scope.
+
+=== Resource control and optimization options ===
+[[PassengerMaxPoolSize]]
+==== passenger_max_pool_size <integer> ====
+The maximum number of Ruby on Rails or Rack application instances that may
+be simultaneously active. A larger number results in higher memory usage,
+but improved ability to handle concurrent HTTP clients.
+
+The optimal value depends on your system's hardware and the server's average
+load. You should experiment with different values. But generally speaking,
+the value should be at least equal to the number of CPUs (or CPU cores) that
+you have. If your system has 2 GB of RAM, then we recommend a value of '30'.
+If your system is a Virtual Private Server (VPS) and has about 256 MB RAM, and
+is also running other services such as MySQL, then we recommend a value of '2'.
+
+If you find that your server is unable to handle the load on your Rails/Rack websites
+(i.e. running out of memory) then you should lower this value. (Though if your
+sites are really that popular, then you should strongly consider upgrading your
+hardware or getting more servers.)
+
+This option may only occur once, in the 'http' configuration bock.
+The default value is '6'.
+
+TIP: We strongly recommend you to <<reducing_memory_usage,use Ruby Enterprise
+Edition>>. This allows you to reduce the memory usage of your Ruby on Rails applications
+by about 33%. And it's not hard to install.
+
+==== passenger_max_instances_per_app <integer> ====
+The maximum number of seconds that an application instance may be idle. That is,
+if an application instance hasn't received any traffic after the given number of
+seconds, then it will be shutdown in order to conserve memory.
+
+Decreasing this value means that applications will have to be spawned
+more often. Since spawning is a relatively slow operation, some visitors may
+notice a small delay when they visit your Rails/Rack website. However, it will also
+free up resources used by applications more quickly.
+
+The optimal value depends on the average time that a visitor spends on a single
+Rails/Rack web page. We recommend a value of `2 * x`, where `x` is the average
+number of seconds that a visitor spends on a single Rails/Rack web page. But your
+mileage may vary.
+
+When this value is set to '0', application instances will not be shutdown unless 
+it's really necessary, i.e. when Phusion Passenger is out of worker processes
+for a given application and one of the inactive application instances needs to
+make place for another application instance. Setting the value to 0 is
+recommended if you're on a non-shared host that's only running a few
+applications, each which must be available at all times.
+
+This option may only occur once, in the 'http' configuration block.
+The default value is '300'.
+
+[[PassengerPoolIdleTime]]
+==== passenger_pool_idle_time <integer> ====
+The maximum number of seconds that an application instance may be idle. That is,
+if an application instance hasn't received any traffic after the given number of
+seconds, then it will be shutdown in order to conserve memory.
+
+Decreasing this value means that applications will have to be spawned
+more often. Since spawning is a relatively slow operation, some visitors may
+notice a small delay when they visit your Rails/Rack website. However, it will also
+free up resources used by applications more quickly.
+
+The optimal value depends on the average time that a visitor spends on a single
+Rails/Rack web page. We recommend a value of `2 * x`, where `x` is the average
+number of seconds that a visitor spends on a single Rails/Rack web page. But your
+mileage may vary.
+
+When this value is set to '0', application instances will not be shutdown unless 
+it's really necessary, i.e. when Phusion Passenger is out of worker processes
+for a given application and one of the inactive application instances needs to
+make place for another application instance. Setting the value to 0 is
+recommended if you're on a non-shared host that's only running a few
+applications, each which must be available at all times.
+
+This option may only occur once, in the 'http' configuration block.
+The default value is '300'.
+
+=== Ruby on Rails-specific options ===
+[[RailsEnv]]
+==== rails_env <string> ====
+This option allows one to specify the default `RAILS_ENV` value.
+
+This option may occur in the following places:
+
+ * In a 'server' configuration block.
+ * In a 'location' configuration block.
+ * In an 'if' configuration scope.
+
+In each place, it may be specified at most once. The default value is 'production'.
+
+==== rails_spawn_method <string> ====
+[TIP]
+."What spawn method should I use?"
+=========================================================
+This subsection attempts to describe spawn methods, but it's okay if you don't (want to)
+understand it, as it's mostly a technical detail. You can basically follow this rule of thumb:
+
+************************************************
+If your application works on Mongrel, but not on Phusion Passenger, then set
+`rails_spawn_method` to 'conservative'. Otherwise, leave it at 'smart-lv2' (the default).
+************************************************
+
+However, we do recommend you to try to understand it. The 'smart' and 'smart-lv2' spawn
+methods bring many benefits.
+=========================================================
+
+include::users_guide_snippets/rails_spawn_method.txt[]
+
+This option may occur in the following places:
+
+ * In the 'http' configuration block.
+ * In a 'server' configuration block.
+ * In a 'location' configuration block.
+ * In an 'if' configuration scope.
+
+In each place, it may be specified at most once. The default value is 'smart-lv2'.
+
+==== rails_framework_spawner_idle_time <integer> ====
+The FrameworkSpawner server (explained in <<spawning_methods_explained,Spawning
+methods explained>>) has an idle timeout, just like the backend processes spawned by
+Phusion Passenger do. That is, it will automatically shutdown if it hasn't done
+anything for a given period.
+
+This option allows you to set the FrameworkSpawner server's idle timeout, in
+seconds. A value of '0' means that it should never idle timeout.
+
+Setting a higher value will mean that the FrameworkSpawner server is kept around
+longer, which may slightly increase memory usage. But as long as the
+FrameworkSpawner server is running, the time to spawn a Ruby on Rails backend
+process only takes about 40% of the time that is normally needed, assuming that
+you're using the 'smart' <<RailsSpawnMethod,spawning method>>. So if your
+system has enough memory, is it recommended that you set this option to a high
+value or to '0'.
+
+This option may occur in the following places:
+
+ * In the 'http' configuration block.
+ * In a 'server' configuration block.
+ * In a 'location' configuration block.
+ * In an 'if' configuration scope.
+
+In each place, it may be specified at most once. The default value is '1800' (30 minutes).
+
+==== rails_app_spawner_idle_time <integer> ====
+The ApplicationSpawner server (explained in <<spawning_methods_explained,Spawning
+methods explained>>) has an idle timeout, just like the backend processes spawned by
+Phusion Passenger do. That is, it will automatically shutdown if it hasn't done
+anything for a given period.
+
+This option allows you to set the ApplicationSpawner server's idle timeout, in
+seconds. A value of '0' means that it should never idle timeout.
+
+Setting a higher value will mean that the ApplicationSpawner server is kept around
+longer, which may slightly increase memory usage. But as long as the
+ApplicationSpawner server is running, the time to spawn a Ruby on Rails backend
+process only takes about 10% of the time that is normally needed, assuming that
+you're using the 'smart' or 'smart-lv2' <<RailsSpawnMethod,spawning method>>. So if your
+system has enough memory, is it recommended that you set this option to a high
+value or to '0'.
+
+This option may occur in the following places:
+
+ * In the 'http' configuration block.
+ * In a 'server' configuration block.
+ * In a 'location' configuration block.
+ * In an 'if' configuration scope.
+
+In each place, it may be specified at most once. The default value is '600' (10 minutes).
+
+=== Rack-specific options ===
+[[RackEnv]]
+==== rack_env <string> ====
+This option allows one to specify the default `RACK_ENV` value.
+
+This option may occur in the following places:
+
+ * In a 'server' configuration block.
+ * In a 'location' configuration block.
+ * In an 'if' configuration scope.
+
+In each place, it may be specified at most once. The default value is 'production'.
+
+
+== Analysis and system maintenance tools ==
+
+include::users_guide_snippets/analysis_and_system_maintenance_tools.txt[]
+
+
+== Tips ==
+
+include::users_guide_snippets/tips.txt[]
+
+
+include::users_guide_snippets/appendix_a_about.txt[]
+
+include::users_guide_snippets/appendix_b_terminology.txt[]
+
+include::users_guide_snippets/appendix_c_spawning_methods.txt[]