Configure Passenger

Sometimes the Ruby agent pushes the application over the timeout threshold and that prevents the server from startup. This can be prevented by server configuration.

Passenger can be configured in Standalone mode or along side HTTP severs: Passenger + NGINX or Passenger + Apache.

The standard way of configuration in Standalone mode goes through these three options:

Command line options:
```
$ passenger start --start-timeout 100
```

Environment variables:

$ env PASSENGER_START_TIMEOUT=100 passenger start

Passengerfile.json (must be located in the application directory):
```
{
  "start_timeout": "100"
}
```

The order of configurations (most to least precedent):

Command line options
Environment variables
Passengerfile.json

Note

An exception is made for mass deployment, then pre-app configurations are overridden both for command line and environment variables.

Passenger in NGINX or Apache mode is configured via the corresponding Apache or NGINX configuration files. These modes don not consult with Passengerfile.json.

# example of an Nginx configuration file which also configures Passenger:

server {
    server_name yourserver.com;
    root /var/www/myapp/code/public;
    passenger_enabled on;
    passenger_ruby /usr/bin/ruby2.0;
    passenger_sticky_sessions on;
}

# example of an Apache configuration file which also configures Passenger:

<VirtualHost *:80>
    ServerName yourserver.com
    DocumentRoot /var/www/myapp/code/public
    PassengerStickySessions on

    <Directory /var/www/myapp/code/public>
        Allow from all
        Options -MultiViews
        Require all granted
    </Directory>
</VirtualHost>

Timeouts

Max request time - The maximum amount of time, in seconds, that an application process may take to process a request. If the request takes longer than this amount of time, then the application process will be forcefully shut down, and possibly restarted upon the next request. A value of 0 means that there is no time limit. This is an enterprise only configuration.
- Default value: 0
- Command line:
```
$ passenger start --max-request-time SECONDS
```
- Environment variables:
- Passengerfile.json:
```
{
   "max_request_time": integer
}
```
Max request queue time - When all concurrent requests are handled and their maximum number is reached, Passenger will queue all incoming requests. This option specifies the maximum time a request may spend in that queue. If a request in the queue reaches this specified limit, then Passenger will send a "504 Gateway Timeout" error for that request. A value of 0 means that the queue time is unbounded. This is an enterprise only configuration.
- Default value: 0
- Command line:
```
$ passenger start --max-request-queue-time NUMBER
```
- Environment variables:
```
PASSENGER_MAX_REQUEST_QUEUE_TIME=integer
```
- Passengerfile.json:
```
{
   "max_request_queue_time": integer
} 
```
Pool idle time - Maximum time for idle application process. If an application process hasn't received any traffic after the given number of seconds, then it will be shutdown in order to conserve memory. When this value is set to 0, application processes will not be shutdown unless manual killed or crush occurs. Decreasing this value means that application processes will have to be spawned more often.
- Default value: 300 (5 minutes)
- Command line:
```
$ passenger start --pool-idle-time SECONDS
```
- Environment variables:
```
PASSENGER_POOL_IDLE_TIME=integer
```
- Passengerfile.json:
```
{
   "pool_idle_time": integer
}
```
Max preload idle time - Timeout for automatically shutdown a preloader process if it hasn't done anything for a given period. This option allows you to set the preloader's idle timeout, in seconds. A value of 0 means that it should never idle timeout. Setting a higher value will mean that the preloader is kept around longer, which may slightly increase memory usage. But as long as the preloader server is running, the time to spawn a Ruby application process only takes about 10% of the time that is normally needed.
- Default value: 300 (5 minutes)
- Command line:
```
$ passenger start --max-preloader-idle-time SECONDS
```
- Environment variables:
```
PASSENGER_MAX_PRELOADER_IDLE_TIME=integer
```
- Passengerfile.json:
```
{
   "max_preloader_idle_time": integer
}
```
Start timeout - Timeout for the startup of application. If an application process fails to start within the timeout period then it will be forcefully killed with SIGKILL, and the error will be logged.
- Default value: 90
- Command line:
```
$ passenger start --start-timeout SECONDS;
```
- Environment variables:
```
PASSENGER_START_TIMEOUT=integer
```
- Passengerfile.json:
```
{
   "start_timeout": integer
}
```

Forking

Passenger is more like a process manager and instead of running application inside its own process space it launches it as external process and handle the management. This includes shut down of unused processes, or restarting them when they crash. An instance of an application is called a process. Passenger takes care of starting and stopping application.

Spawning is when Passenger starts an instance of an application. There are two methods for spawning an application in Passenger:

Direct: new Ruby process with full copy of the application code and the web framework in memory. This approach uses more memory and takes more time to start.
Smart: For Ruby apps this method is default. It begins with 'preloader' process. This process loads the entire application along with the web framework, by loading the file config.ru. The preloader process doesn't participate in request handling. Whenever new application process is needed the preloader spawns a child process (with the fork() system call).
The command used for creating a new fork is:
```
$ bundle exec passenger start --min-instances 2
```
This tells Passenger to keep 2 instances of the application.
- Default value: 1
- Default pool size for instances: 6
- Passengerfile.json:
```
{
  "max_pool_size": 6
}
```

When a request is handled, Passenger will pass it to the process with the least number of requests. If a process is killed, it is restarted automatically. Processes are also dynamically scaled, depending on traffic, spawning new forks up to the maximum pool number.

Configure Passenger

Note

Timeouts

Forking

See also

Search results