10

これをnginxメーリングリストに投稿しましたが、誰からも返事がなかったので、ここでstackoverflowで試してみようと思いました:)

現在、Amazon EC2 でホストされている Django アプリを使用しています。私のデータはすべて、ポート 8000 の Gunicorn (UNIX 用の Python WSGI HTTP サーバー。これは、Ruby の Unicorn プロジェクトから移植されたフォーク前のワーカー モデルです) を介して提供されます。静的コンテンツ (画像) をクライアントに渡すことはすべて Amazon の S3 サービスによって処理されるため、心配する必要はありません。Django は、コンテンツの URL を Gunicorn 経由で json 経由でクライアントに渡します。その後、クライアントはそれをダウンロードできます。

私の Django アプリは t1.micro インスタンスでホストされています。アマゾン ウェブ サービスが提供する仕様は次のとおりです。

プロセッサ: 最大 2 つの EC2 コンピューティング ユニット (短い定期的なバースト用)。仮想コア: 1 メモリ: 615 MiB プラットフォーム: 32 ビットおよび 64 ビット

このインスタンスでは、Django アプリと一緒に 3 つの Gunicorn ワーカーを実行しています。

私の Nginx リバース プロキシ サーバーには、t1.micro インスタンスも使用しています。私はそれをセットアップしましたが、すべてが完全に正常に機能しています。以下は、私の etc/nginx/sites-enabled/default 構成です。

# Gunicorn server
upstream django {
  server         10.0.10.0:8000;
}
# Serve static files and redirect any other request to Gunicorn
server {
  listen       80;
  server_name  23.0.23.23/;
  #root        /var/www/domain.com/;
  #access_log  /var/log/nginx/domain.com.access.log;
  #error_log  /var/log/nginx/domain.com.error.log;

  # Check if a file exists at /var/www/domain/ for the incoming request.
  # If it doesn't proxy to Gunicorn/Django.
  #try_files $uri @django;

  # Setup named location for Django requests and handle proxy details
  location @django {
    proxy_pass         http://django;
    proxy_redirect     off;
    proxy_set_header   Host             $host;
    proxy_set_header   X-Real-IP        $remote_addr;
    proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
  }
}

このセットアップは素晴らしいですが、遅いクライアントのプロキシ バッファリングを考慮していません。また、キャッシングも考慮されておらず、必要な nginx ワーカーの数も考慮されていません。圧縮を構成するにはどうすればよいですか? gzip と呼ばれるものがあると述べているリソースを見つけましたが、これは json をサポートしていますか? t1.micro インスタンスの仕様に従って、nginx 構成を微調整するにはどうすればよいですか?

あなたが私のシナリオにいる場合、どの設定を使用しますか? あなたの答えと例は大歓迎です。ありがとうございました ：）

4

1 に答える 1

6

プロキシ バッファリング

一般に、プロキシ バッファリングは、非常に大きな Web ページを生成する場合、または大きなファイルを送信する場合にのみ役立ちます。いずれにせよ、セットアップは非常に簡単ですが、バッファー サイズを最大ページのサイズ +20% 程度に調整する必要があります (バッファーに収まらないページはすべてディスクに書き込まれます)。あなたの最大のページ。

ドキュメント: http://wiki.nginx.org/HttpProxyModule#proxy_buffering

キャッシング

あなたのアプリとそのコンテンツがどれほど動的であるかについてはあまり知りませんが、アプリで正しいキャッシュ コントロール/ETAG ヘッダー生成を設定することは、最初に確認したいことです。これは、Nginx にプロキシしても安全なものを知らせるものです。また、複数のキャッシュ ゾーンをセットアップして、キャッシュがディスク上で使用する容量を管理することもできます。

proxy_cache one;
proxy_cache_path  /data/nginx/cache/one levels=1:2 max_size=1G keys_zone=one:1000m;

キャッシュをバイパスできるルールが必要になります（デバッグまたはプログラムで）

proxy_cache_bypass $cookie_nocache $arg_nocache $arg_comment;
proxy_cache_bypass $http_pragma $http_authorization;

また、アプリケーションがエラーをスローしたときに、無条件にキャッシュからアプリを提供する必要があります。

proxy_cache_use_stale error timeout invalid_header;

ドキュメント:

Gzip

サイトで gzip を有効にすると、常に CPU 時間と帯域幅のトレードオフが生じます。確かに、コンテンツを gzip で圧縮すれば、ネットワーク経由で送信されるデータの量を減らすことができますが、T1 Micro で実行している場合は、CPU 使用率のためにプロキシ リクエストの容量が大幅に制限されます。一般に、gzip は、事前に圧縮してから何度も何度も提供できる静的コンテンツにははるかに優れたアイデアです。

(はい、gzip は json をサポートしていますが、これは gzip がワイヤ形式になり、クライアントによって透過的に解凍されるためです。 を読んでくださいContent-Encoding: gzip)

ドキュメント: http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/

その他

いくつかのその他の設定も設定する必要があります。

# Directives turn off 404 error logging.
location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    log_not_found off;
}
于 2013-06-08T04:01:11.980 に答える