Reputation: 1595
I'm using the open source version of Passenger 4.0.17 and trying to discern something about it's behavior that is not clear to me from the documentation. I'm hoping someone can help.
Is there a difference between doing this:
server {
listen 443;
server_name www.example.com;
root /path/to/my/app/public;
location / {
passenger_enabled on;
rails_env production;
# etc. ....
}
}
And doing this?
server {
listen 443;
server_name www.example.com;
root /path/to/my/app/public;
try_files $uri @passenger
location @passenger {
passenger_enabled on;
rails_env production;
# etc. ....
}
}
I've been in the habit of doing the first, but I'm starting to wonder if the second is better.
I would expect that in the first example, Passenger worker processes handle EVERY request and that in the second example, Passenger worker processes handle only those requests for which Nginx can't serve a static response.
But...
In the back of my mind, I wonder if the Passenger module for Nginx doesn't already have that level of intelligence built in- making the try_files directive unnecessary. (If the try_files directive as used above kept Passenger from handling requests that Nginx could handle on its own, I would expect that to have been covered in the Passenger documentation, right? But there is no mention of it at all.)
The reason for asking is obvious...
If I can serve static content from Nginx worker processes without having to both the Passenger worker processes, those Passenger processes (which take up more memory and are less efficient in comparison) will be free to handle the requests they really NEED to handle and I'll get more bang for my buck with just a small number of workers.
Again... I can't see where the documentation covers this at all. Any info from someone in the know would be greatly appreciated!
Upvotes: 4
Views: 1590
Reputation: 1595
Answered here by Phusion employees:
https://groups.google.com/forum/#!topic/phusion-passenger/nDkYVJhYkuw
Short version: They're functionally equivalent.
Upvotes: 2