2017-05-16 19 views
1

免責事項:これは技術的に学校プロジェクトに関連していますが、私は教授と話をしており、これもまた混乱しています。nginxとuwsgi:上流の応答時間と要求時間の差が大きい

私は、いくつかのuwsgi +フラスコアプリへのnginxロードバランサ逆プロキシを持っています。アプリは非常に高いスループット/負荷を処理するためのものです。 uwsgiからの私の応答時間はかなり良いですし、nginxサーバーのCPU使用率と負荷平均は低いですが、全体の要求時間は非常に高いです。

私はこの問題を調査しましたが、私が見つけたすべてのスレッドでは、これは常にクライアントの接続が遅いために発生すると言われています。しかし、リクエストは同じネットワーク上のスクリプトによって作成されています。この問題は他の誰の設定にも影響しません。したがって、それは私のnginx設定の問題です。これは、nginxがこのようなボトルネックになるのはほとんど予期しないように思われるので、私は完全に困惑しています。

問題の大きさを知るには、画像の追加、検索、追加ツイート(これはツイッタークローン)の3つの主要なリクエストタイプがあります。

画像を追加する場合、全体の要求時間は、アップストリームの平均応答時間よりも約20倍長くなります。検索の場合は3倍で、ツイート1.5を追加します。ここでの違いは、検索や追加のどちらのツイートよりも、画像を前後に送るデータの量がはるかに多く、検索にはツイートを追加するよりもデータの量が多いということです。

私nginx.confは次のとおりです。

user www-data; 
pid /run/nginx.pid; 

worker_processes auto; 
worker_rlimit_nofile 30000; 
events { 
    worker_connections 30000; 
} 

http { 
    # Settings. 
    sendfile on; 
    tcp_nopush on; 
    tcp_nodelay on; 
    client_body_buffer_size 200K; 
    keepalive_timeout 65; 
    types_hash_max_size 2048; 

    include /etc/nginx/mime.types; 
    default_type application/octet-stream; 

    # SSL. 
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; 
    ssl_prefer_server_ciphers on; 

    # Logging 
    log_format req_time '$remote_addr - $remote_user [$time_local] ' 
         'REQUEST: $request ' 
       'STATUS: $status ' 
       'BACK_END: $upstream_addr ' 
       'UPSTREAM_TIME: $upstream_response_time s ' 
       'REQ_TIME: $request_time s '; 
       'CONNECT_TIME: $upstream_connect_time s'; 
    error_log /var/log/nginx/error.log; 
    access_log /var/log/nginx/access.log req_time; 


    # GZIP business 
    gzip on; 
    gzip_disable "msie6"; 

    # Routing. 
    upstream media { 
     server 192.168.1.91:5000; 
    } 

    upstream search { 
     least_conn; 
     server 192.168.1.84:5000; 
     server 192.168.1.134:5000; 
    } 

    upstream uwsgi_app { 
     least_conn; 
     server 192.168.1.85:5000; 
     server 192.168.1.89:5000; 
     server 192.168.1.82:5000; 
     server 192.168.1.125:5000; 
     server 192.168.1.86:5000; 
     server 192.168.1.122:5000; 
     server 192.168.1.128:5000; 
     server 192.168.1.131:5000; 
     server 192.168.1.137:5000;  
    } 

    server { 
     listen 80; 
     server_name localhost; 

     location /addmedia { 
      include uwsgi_params; 
     uwsgi_read_timeout 5s; 
     proxy_read_timeout 5s; 
      uwsgi_pass media; 
     } 

     location /media { 
      include uwsgi_params; 
     uwsgi_read_timeout 5s; 
     proxy_read_timeout 5s; 
      uwsgi_pass media; 
     } 

     location /search { 
      include uwsgi_params; 
     uwsgi_read_timeout 5s; 
     proxy_read_timeout 5s; 
      uwsgi_pass search; 
     } 

     location /time-search { 
      rewrite /time-search(.*) /times break; 
         include uwsgi_params; 
         uwsgi_pass search; 
     } 

     location /item { 
      include uwsgi_params; 
     uwsgi_read_timeout 5s; 
     proxy_read_timeout 5s; 
      if ($request_method = DELETE) { 
       uwsgi_pass media; 
      } 

      if ($request_method = GET) { 
       uwsgi_pass uwsgi_app; 
      } 

      if ($request_method = POST) { 
       uwsgi_pass uwsgi_app; 
      } 
     } 

     location/{ 
      include uwsgi_params; 
     uwsgi_read_timeout 5s; 
     proxy_read_timeout 5s; 
      uwsgi_pass uwsgi_app; 
     } 
    } 
} 

そして、私のuwsgiのINIは次のようになります。この問題の原因についての

[uwsgi] 
chdir = /home/ubuntu/app/ 
module = app 
callable = app 
master = true 
processes = 25 
socket = 0.0.0.0:5000 
socket-timeout = 5 
die-on-term = true 
home = /home/ubuntu/app/venv/ 
uid = 1000 
buffer-size=65535 
single-interpreter = true 

任意の洞察力をいただければ幸いです。

答えて

1

私はこれを考え出したと思います。 nginxのドキュメント(https://www.nginx.com/blog/using-nginx-logging-for-application-performance-monitoring/)を読むことで、注目すべき3つのメトリクスがあると思われます:upstream_response_time、request_time、およびupstream_connect_time。私はupstream_response_timeとrequest_timeの違いに焦点を合わせました。

ただし、upstream_response_timeは、要求を受け入れて応答を返す上流間の時間です。 upstream_connect時間、またはアップストリーム・サーバーへの接続の確立に要する時間は含まれません。また、uwsgiのコンテキストでは、これは非常に重要です。なぜなら、要求を受け入れることができるワーカーがいなければ、要求はバックログに置かれるからです。 uwsgiはまだバイトを読み取っていないので、リクエストがバックログで待機する時間はupstream_connect_timeとカウントされ、nginxではupstream_response_timeではないと考えられます。

残念ながら、私はupstream_connect_timeを記録していた場所では「遅い」実行を得られないので、100%確実にすることはできません。しかし、私が変えた唯一の事柄は、「uwsgiをもっと速くする」という変更(検索にもっと多くのコアを捧げ、DBを高速化するためにDB内の複製要素を増やすこと)だけだった... ...そうだ。アプリのスループットを向上させる。