5

だから、トルネード ワーカーを実行している gunicorn で実行されている単純な Flask API アプリケーションがあります。gunicorn のコマンド ラインは次のとおりです。

gunicorn -w 64 --backlog 2048 --keep-alive 5 -k tornado -b 0.0.0.0:5005 --pid /tmp/gunicorn_api.pid api:APP

Apache Benchmark を別のサーバーから直接 gunicorn に対して実行すると、関連する結果が次のようになります。

ab -n 1000 -c 1000 'http://****:5005/v1/location/info?location=448&ticket=55384&details=true&format=json&key=****&use_cached=true'
Requests per second:    2823.71 [#/sec] (mean)
Time per request:       354.144 [ms] (mean)
Time per request:       0.354 [ms] (mean, across all concurrent requests)
Transfer rate:          2669.29 [Kbytes/sec] received

そのため、パフォーマンスは毎秒 3,000 リクエストに近づいています。

今、私はSSLが必要です。nginx をリバース プロキシとして実行しています。以下は、同じサーバー上の nginx に対する同じベンチマークの結果です。

ab -n 1000 -c 1000 'https://****/v1/location/info?location=448&ticket=55384&details=true&format=json&key=****&use_cached=true'
Requests per second:    355.16 [#/sec] (mean)
Time per request:       2815.621 [ms] (mean)
Time per request:       2.816 [ms] (mean, across all concurrent requests)
Transfer rate:          352.73 [Kbytes/sec] received

これは、87.4% のパフォーマンスの低下です。しかし、私の人生では、nginxのセットアップの何が問題なのかわかりません。これはどれですか：

upstream sdn_api{
    server 127.0.0.1:5005;

    keepalive 100;
}

server {
        listen [::]:443;

    ssl on;
    ssl_certificate /etc/ssl/certs/api.sdninja.com.crt;
    ssl_certificate_key /etc/ssl/private/api.sdninja.com.key;
    ssl_protocols SSLv3 TLSv1;
    ssl_ciphers ALL:!kEDH:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM;
    ssl_session_cache shared:SSL:10m;

    server_name api.*****.com;
    access_log  /var/log/nginx/sdn_api.log;

    location / {
        proxy_pass http://sdn_api;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        client_max_body_size 100M;
        client_body_buffer_size 1m;
        proxy_intercept_errors on;
        proxy_buffering on;
        proxy_buffer_size 128k;
        proxy_buffers 256 16k;
        proxy_busy_buffers_size 256k;
        proxy_temp_file_write_size 256k;
        proxy_max_temp_file_size 0;
        proxy_read_timeout 300;
    }

}

そして私のnginx.conf：

user www-data;
worker_processes 8;
pid /var/run/nginx.pid;

events {
    worker_connections 2048;
    # multi_accept on;
}

http {

    ##
    # Basic Settings
    ##

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

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

    ##
    # Logging Settings
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Gzip Settings
    ##

    gzip off;
    gzip_disable "msie6";

    # gzip_vary on;
    # gzip_proxied any;
    # gzip_comp_level 6;
    # gzip_buffers 16 8k;
    # gzip_http_version 1.1;
    # gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    ##
    # nginx-naxsi config
    ##
    # Uncomment it if you installed nginx-naxsi
    ##

    #include /etc/nginx/naxsi_core.rules;

    ##
    # nginx-passenger config
    ##
    # Uncomment it if you installed nginx-passenger
    ##

    #passenger_root /usr;
    #passenger_ruby /usr/bin/ruby;

    ##
    # Virtual Host Configs
    ##

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

では、この構成で実行が非常に遅い理由を知っている人はいますか? ありがとう！

4

1 に答える 1

2

HTTPS オーバーヘッドの大部分はハンドシェイクにあります。-k を ab に渡して、永続的な接続を有効にします。ベンチマークが大幅に高速化されていることがわかります。

于 2013-05-05T18:49:58.030 に答える