4

私は Passenger 4.0.17 のオープン ソース バージョンを使用しており、その動作について、ドキュメントからは明らかでないことを識別しようとしています。誰かが助けてくれることを願っています。

これを行うことに違いはありますか：

server {
    listen         443;
    server_name    www.example.com;

    root           /path/to/my/app/public;

    location / {
        passenger_enabled      on;
        rails_env              production;
        # etc. ....
    }

}

そして、これを行う？

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

}

私は前者をするのが習慣になっていますが、後者の方が良いのではないかと思い始めています.

最初の例では、パッセンジャー ワーカー プロセスがすべてのリクエストを処理し、2 番目の例では、パッセンジャー ワーカー プロセスが Nginx が静的応答を提供できないリクエストのみを処理することを期待します。

しかし...

心の奥底では、Nginx の Passenger モジュールにはそのレベルのインテリジェンスが組み込まれておらず、try_files ディレクティブは不要なのではないかと考えています。(上記の try_files ディレクティブにより、Nginx が独自に処理できるリクエストを Passenger が処理できなかった場合、それは Passenger のドキュメントでカバーされていると思いますが、それについてはまったく言及されていません。)

質問する理由は明らかです...

Passenger ワーカー プロセスの両方を必要とせずに Nginx ワーカー プロセスから静的コンテンツを提供できれば、それらの Passenger プロセス (メモリを消費し、比較すると効率が悪い) は、実際に処理する必要がある要求を自由に処理できるようになります。少数のワーカーだけで、より大きな成果が得られます。

繰り返しますが...ドキュメントがこれをカバーしている場所がまったくわかりません。詳しい方からの情報は大変助かります！

4

1 に答える 1

2

Phusion の従業員による回答:

https://groups.google.com/forum/#!topic/phusion-passenger/nDkYVJhYkuw

短いバージョン: 機能的に同等です。

于 2013-09-16T21:04:53.537 に答える