Nginx + Phusion Passenger try_files

J’utilise la version open source de Passenger 4.0.17 et essaye de discerner quelque chose à propos de son comportement qui ne me semble pas clair dans la documentation. J’espère que quelqu’un peut aider.

Y a-t-il une différence entre faire ceci:

server { listen 443; server_name www.example.com; root /path/to/my/app/public; location / { passenger_enabled on; rails_env production; # etc. .... } } 

Et faire ça?

 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. .... } } 

J’ai l’habitude de faire le premier, mais je commence à me demander si le second est meilleur.

• Comment développer et déployer des applications Catalyst fastcgi avec des URI nginx et personnalisés?
• Impossible de télécharger l’image sur wordpress (nginx + vernis + apache)
• Nginx Config Location Regex avec le code de langue dans l’url
• jQuery.ajax ne retourne pas de réponse (CORS échoue)
• Lazy Load Django Admin Inlines

Je m’attendrais à ce que, dans le premier exemple, les processus de travail Passenger gèrent TOUTES les requêtes et que, dans le second exemple, les processus de travail Passenger ne gèrent que les requêtes pour lesquelles Nginx ne peut pas répondre de manière statique.

Mais…

Au fond de mon esprit, je me demande si le module Passenger de Nginx ne possède pas déjà ce niveau d’intelligence, rendant la directive try_files inutile. (Si la directive try_files, telle qu’utilisée ci-dessus, empêchait Passenger de traiter les requêtes que Nginx pouvait traiter par lui-même, je m’attendrais à ce que cela soit traité dans la documentation Passager, n’est-ce pas?)

La raison de demander est évidente …

Si je peux servir du contenu statique à partir de processus de travail Nginx sans avoir à effectuer les deux processus de travail Passenger, ces processus Passenger (qui consumnt plus de mémoire et sont moins efficaces en comparaison) seront libres de traiter les demandes qu’ils doivent vraiment gérer. Je vais faire plus pour mon argent avec un petit nombre de travailleurs.

Encore une fois … Je ne vois pas où la documentation couvre cela du tout. Toute information de quelqu’un de connu serait grandement appréciée!

• Nginx comme proxy pour le serveur webSocket était lent à envoyer des données volumineuses
• Faire en sorte que nginx réécrit
• Nginx + uwsgi ne donne pas de contenu quand post a un 401
• AngularJS + Sailsjs + Nginx = date incorrecte de UTC
• Rails L’index du répertoire nginx est interdit