Where is passenger config

Passenger provides a wide range of features and customization options. Some of them are for improving or tweaking the application's performance characteristics, some of them influence application or connection handling behavior, etc.

Please visit the configuration index page to learn what you can configure. What is this? This temporary directory is called the instance directory. It contains all sorts of files that are important to that specific running Passenger instance, such as Unix domain socket files so that all the different Passenger processes can communicate with each other. Command line tools such as passenger-status use the files in this directory in order to query Passenger's status.

It is therefore important that, while Passenger is working, the instance directory is never removed or tampered with. However, the default path for the instance registry directory is the system's temporary directory, and some systems may run background jobs that periodically clean this directory.

If this happens, and the files inside the instance directory are removed, then it will cause Passenger to malfunction: Passenger won't be able to communicate with its own processes, and you will see all kinds of connection errors in the log files. This malfunction can only be recovered from by restarting Nginx. You can prevent such cleaning background jobs from interfering by setting this option to a different directory. This option is also useful if the partition that the temporary directory lives on doesn't have enough disk space.

This option has no effect when you are using Flying Passenger. Instead, you should configure this by passing the --instance-registry-dir command line option to the Flying Passenger daemon.

Some Passenger command line administration tools, such as passenger-status , must know what Passenger's instance registry directory is in order to function properly. Enables the Flying Passenger mode, and configures Nginx to connect to the Flying Passenger daemon that's listening on the given socket filename. Sets the file descriptor operating system ulimit for the Passenger core process. If you see "too many file descriptors" errors on a regular basis, then increasing this limit will help.

The default value is inherited from the process that started Passenger, which is the Nginx master process in the Nginx integration mode. Assuming Passenger has enough access rights normally true if the Nginx master process runs as root , it can override its ulimit to the requested setting. This Passenger configuration option provides an easier and high confidence way to set the file descriptor ulimit.

Note that application ulimits may also be affected by this setting because ulimits are inherited on a process basis i. There are two exceptions to this:. Sets the file descriptor operating system ulimit for application processes managed by Passenger. If you see "too many file descriptor" errors on a regular basis, and these errors originate from the application process as opposed to the Passenger core processes , then increasing this limit will help.

If the "too many file descriptor" errors originate from the Passenger core process, then setting this option will not help. The default file descriptor ulimit is inherited from the Passenger core process. The maximum number of application processes that may simultaneously exist.

A larger number results in higher memory usage, but improves the ability to handle concurrent HTTP requests. The optimal value depends on your system's hardware and your workload.

Please read the optimization guide to learn how to find out the optimal value. This option behaves like a "safety switch" that prevents Passenger from overloading your system with too many processes. If you find that your server is running out of memory then you should lower this value. In order to prevent your server from crashing due to out-of-memory conditions, the default value is relatively low 6.

Instead, you should configure this by passing the --max-pool-size command line option to the Flying Passenger daemon. This specifies the minimum number of application processes that should exist for a given application.

You should set this option to a non-zero value if you want to avoid potentially long startup times after a website has been idle for an extended period of time. Please note that this option does not pre-start application processes during Nginx startup.

It just makes sure that when the application is first accessed:. When you start Nginx, there are 0 application processes for 'foobar. Things will stay that way until someone visits 'foobar. Suppose that there is only one visitor. One application process will be started immediately to serve the visitor, while two will be spawned in the background. After 10 seconds, when the idle timeout has been reached, these 3 application processes will not be cleaned up.

Now suppose that there's a sudden spike of traffic, and users visit 'foobar. After the idle timeout of 10 seconds has passed, Passenger will clean up 12 application processes, keeping 3 processes around. The maximum number of application processes that may simultaneously exist for an application. This helps to make sure that a single application will not occupy all available slots in the application pool.

A value of 0 means that there is no limit placed on the number of processes a single application may spawn, i. Suppose that you're hosting two web applications on your server, a personal blog and an e-commerce website.

The e-commerce website is more important to you. Your e-commerce website on the other hand will be free to spawn up to 10 processes if it gets a lot of traffic. The maximum number of application processes that may simultaneously exist for a single application. A value of 0 means that there is no limit placed on the number of processes a single application may use, i.

Under normal circumstances, if blog A suddenly gets a lot of traffic, then A will use all 10 pool slots. If blog B suddenly gets some traffic, then it will only be able to use 1 pool slot forcefully releasing 1 slot from A until A's traffic has settled down and it has released more pool slots. This way, both blogs will never use more than 5 pool slots. Your e-commerce website on the other hand will be free to use up all 10 slots if it gets a lot of traffic. The maximum number of seconds that an application process may be idle.

That is, 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. 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 web app.

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 dynamic page.

But your mileage may vary. When this value is set to 0 , application processes will not be shutdown unless it's really necessary. Here is a situation where Passenger seems necessary to shutdown an application process. Suppose that you have two apps on your server, foo and bar. If a user visits foo, but there are no processes for foo, and at the same time there are lots of application processes for bar as many as the pool limit , then Passenger will wait until one of those bar processes is no longer handling a request.

At time time, that process will be shutdown so that Passenger can spawn a foo process. 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.

Instead, you should configure this by passing the --pool-idle-time command line option to the Flying Passenger daemon. The preloader process explained in Spawn methods has an idle timeout, just like the application processes spawned by Passenger do. That is, it will 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. So if your system has enough memory, then is it recommended that you set this option to a high value or to 0. Use this option to tell Passenger how many concurrent requests the application can handle per process.

A value of 0 means that each process can handle an unlimited number of connections, while a value of -1 the default means that Passenger will infer the value based on internal heuristics. This option is a hint to Passenger and does not make the application actually able to handle that many concurrent requests per process.

For example in Ruby applications, the amount of concurrency that your application process can handle usually depends on the number of configured threads. If you set the number of threads, then Passenger will automatically infer that Ruby applications' max concurrency per process equals the number of threads.

But in non-standard cases where this heuristic fails e. It is recommended that you do not touch this configuration option unless you want to tweak Passenger for one of the two main use cases documented above. Passenger supports two concurrency models:. Specifies the number of threads that Passenger should spawn per Ruby application process. By default, Passenger performs several filesystem checks or, in programmers jargon, " stat calls" each time a request is processed:.

Replace this Please enjoy Phusion Passenger, a product by Phusion. Skip to content. Star Demonstrates running a Ruby app on Heroku with Phusion Passenger stars 20 forks. Branches Tags. Could not load branches. Could not load tags. Latest commit. Git stats 77 commits. Failed to load latest commit information. View code. Running a Ruby app on Heroku with Phusion Passenger Phusion Passenger is an application server, designed to be fast, robust and lightweight.

Can I still use something like the following, if my Rails app is using full page caching to the file system? The files get written out with the. Anyway, nginx upstream module help you in both cases: 1 use Unicorn, 2 use Standalone Passenger. Proxy configs was useless. SSL is not secure. TLS is the new black. Skip to content. Sign in Sign up. Instantly share code, notes, and snippets. Created Nov 23, Code Revisions 32 Stars Forks Embed What would you like to do?