求助：Nginx反向代理到IIS，https方式导致Windows的LSASS进程占用CPU很高

powerdesigner

CentOS版本：7.3.1611

OpenResty版本：1.13.6.2

Windows版本：Win2016DataCenter（非AD，普通工作组）

Nginx采用https反向代理到后端Windows的IIS时导致lsass.exe占用CPU较高。验证发现采用变量形式CPU就很高，压测时占用50%左右，而采用注释的那一句直接proxypass到指定IP端口lsass.exe占用在5%-8%左右。

    server {
        listen 443 ssl;

        ssl_certificate /usr/local/openresty/nginx/cert/bundle.crt;
        ssl_certificate_key /usr/local/openresty/nginx/cert/ckey.key;

        error_page   500 502 503 504  /50x.html;
        
        location /api/ {            
            set $target "192.168.0.2:18099";
            proxy_pass https://$target;
            #proxy_pass https://192.168.0.2:18099;            
        }
    }

1、曾尝试使用ssl相关参数，但不起作用

ssl_session_timeout 10m;

ssl_session_cache shared:SSL:50m;

ssl_session_tickets on;

2、压测工具不走Nginx反向代理，直接压测IIS没问题，w3wp进程可以打满，lsass占用CPU极低

3、分析网络发现，走Nginx反向代理时，每条新的connection都不重用SSL/TLS的会话ID

zchao1995

Hello!

虽然使用变量是会产生一定内存和性能上的开销，但是应该不至于差这么多。

建议使用 perf 或者 systemtap 这样的工具做下分析。

https://github.com/openresty/openresty-systemtap-toolkit

liulantao

1 这几个参数目的是调节nginx对用户端的ssl，还是与proxy后端的ssl参数？貌似需要确认一下。

2 压测工具参数是什么？

3 需要 upstream keepalive 才可能能重用连接。

http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

On Wed, Jun 13, 2018 at 11:03 AM Jimmy Yu <powerd...@gmail.com> wrote:

CentOS版本：7.3.1611
OpenResty版本：1.13.6.2
Windows版本：Win2016DataCenter（非AD，普通工作组）

Nginx采用https反向代理到后端Windows的IIS时导致lsass.exe占用CPU较高。验证发现采用变量形式CPU就很高，压测时占用50%左右，而采用注释的那一句直接proxypass到指定IP端口lsass.exe占用在5%-8%左右。

    server {
listen 443 ssl;

        ssl_certificate /usr/local/openresty/nginx/cert/bundle.crt;
    ssl_certificate_key /usr/local/openresty/nginx/cert/ckey.key;

error_page 500 502 503 504 /50x.html;

        location /api/ {
            set $target "192.168.0.2:18099";
            proxy_pass https://$target;
            #proxy_pass https://192.168.0.2:18099;
        }
    }

1、曾尝试使用ssl相关参数，但不起作用
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets on;
2、压测工具不走Nginx反向代理，直接压测IIS没问题，w3wp进程可以打满，lsass占用CPU极低
3、分析网络发现，走Nginx反向代理时，每条新的connection都不重用SSL/TLS的会话ID

--

Sent from Gmail Mobile

powerdesigner

1、我对这几个参数也不是特别熟悉，从网上资料看像是会对SSL Session复用有好处；

2、压测工具使用JMeter

3、根据您的建议，我修改了测试原型，采用如下形式，虽然也是传递变量，但是指向了固定的Upstream，压测发现CPU降下来了（即使我注释了keepalive效果也一样），但我的使用场景无法采用固定Upstream方式，因为我的后端服务器是变动的，不能每次调整都更改Upstream并Reload。

    upstream sg_ssl{
        server 192.168.0.2:18099;
        keepalive 32;
    }
        ssl_certificate /usr/local/openresty/nginx/cert/bundle.crt;
        ssl_certificate_key /usr/local/openresty/nginx/cert/ckey.key;

        error_page   500 502 503 504  /50x.html;
        
        location /api/ {            
            set  $target "sgmain_ssl";
            proxy_pass https://$target;
        }
    }

在 2018年6月13日星期三 UTC+8下午4:48:29，Liu Lantao写道：

1 这几个参数目的是调节nginx对用户端的ssl，还是与proxy后端的ssl参数？貌似需要确认一下。

2 压测工具参数是什么？

3 需要 upstream keepalive 才可能能重用连接。
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

On Wed, Jun 13, 2018 at 11:03 AM Jimmy Yu <powerd...@gmail.com> wrote:
CentOS版本：7.3.1611
OpenResty版本：1.13.6.2
Windows版本：Win2016DataCenter（非AD，普通工作组）

Nginx采用https反向代理到后端Windows的IIS时导致lsass.exe占用CPU较高。验证发现采用变量形式CPU就很高，压测时占用50%左右，而采用注释的那一句直接proxypass到指定IP端口lsass.exe占用在5%-8%左右。

    server {
listen 443 ssl;

        ssl_certificate /usr/local/openresty/nginx/cert/bundle.crt;
    ssl_certificate_key /usr/local/openresty/nginx/cert/ckey.key;

error_page 500 502 503 504 /50x.html;

        location /api/ {
            set $target "192.168.0.2:18099";
            proxy_pass https://$target;
            #proxy_pass https://192.168.0.2:18099;
        }
    }

1、曾尝试使用ssl相关参数，但不起作用
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets on;
2、压测工具不走Nginx反向代理，直接压测IIS没问题，w3wp进程可以打满，lsass占用CPU极低
3、分析网络发现，走Nginx反向代理时，每条新的connection都不重用SSL/TLS的会话ID

--

--
Sent from Gmail Mobile

hongliang5316

Hello

1. ssl_session* 指令是针对服务端ssl的优化支持, 并不会对proxy的ssl客户端进行优化, 如要开启proxy的session id复用功能可以添加如下指令 `proxy_ssl_session_reuse on`(注意该指令是默认开启的) http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_session_reuse

2. OpenResty是可以实现动态upstream的, 详见: https://github.com/openresty/lua-nginx-module#balancer_by_lua_block

在 2018年6月13日星期三 UTC+8下午8:21:45，Jimmy Yu写道：

1、我对这几个参数也不是特别熟悉，从网上资料看像是会对SSL Session复用有好处；
2、压测工具使用JMeter
3、根据您的建议，我修改了测试原型，采用如下形式，虽然也是传递变量，但是指向了固定的Upstream，压测发现CPU降下来了（即使我注释了keepalive效果也一样），但我的使用场景无法采用固定Upstream方式，因为我的后端服务器是变动的，不能每次调整都更改Upstream并Reload。
    upstream sg_ssl{
        server 192.168.0.2:18099;
        keepalive 32;
    }
        ssl_certificate /usr/local/openresty/nginx/cert/bundle.crt;
    ssl_certificate_key /usr/local/openresty/nginx/cert/ckey.key;

error_page 500 502 503 504 /50x.html;

        location /api/ {
            set $target "sgmain_ssl";
            proxy_pass https://$target;
        }
    }

在 2018年6月13日星期三 UTC+8下午4:48:29，Liu Lantao写道：

1 这几个参数目的是调节nginx对用户端的ssl，还是与proxy后端的ssl参数？貌似需要确认一下。

2 压测工具参数是什么？

3 需要 upstream keepalive 才可能能重用连接。
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

On Wed, Jun 13, 2018 at 11:03 AM Jimmy Yu <powerd...@gmail.com> wrote:
CentOS版本：7.3.1611
OpenResty版本：1.13.6.2
Windows版本：Win2016DataCenter（非AD，普通工作组）

Nginx采用https反向代理到后端Windows的IIS时导致lsass.exe占用CPU较高。验证发现采用变量形式CPU就很高，压测时占用50%左右，而采用注释的那一句直接proxypass到指定IP端口lsass.exe占用在5%-8%左右。

    server {
listen 443 ssl;

        ssl_certificate /usr/local/openresty/nginx/cert/bundle.crt;
    ssl_certificate_key /usr/local/openresty/nginx/cert/ckey.key;

error_page 500 502 503 504 /50x.html;

        location /api/ {
            set $target "192.168.0.2:18099";
            proxy_pass https://$target;
            #proxy_pass https://192.168.0.2:18099;
        }
    }

1、曾尝试使用ssl相关参数，但不起作用
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets on;
2、压测工具不走Nginx反向代理，直接压测IIS没问题，w3wp进程可以打满，lsass占用CPU极低
3、分析网络发现，走Nginx反向代理时，每条新的connection都不重用SSL/TLS的会话ID

--

--
Sent from Gmail Mobile

powerdesigner

1、我已经试过加proxy_ssl_session_reuse on参数，没效果

2、下午我用balancer_by_lua_block+ngx.balancer的方式验证了一遍，也是如此，感觉就是Nginx发出的请求没复用SSL的SessionID

    upstream balancer_ssl {
        server 0.0.0.1;
        balancer_by_lua_block {
            local balancer = require "ngx.balancer"
            local host = "10.80.0.23"
            local port = 18099

            local ok, err = balancer.set_current_peer(host, port)
            if not ok then
                ngx.log(ngx.ERR, "failed to set the current peer: ", err)
                return ngx.exit(500)
            end
        }
        keepalive 32;
    }

...
server {
    location /api/ {
...
            set  $target "balancer_ssl";
            proxy_pass https://$target;
...

在 2018年6月15日星期五 UTC+8下午1:16:36，hongli...@gmail.com写道：

Hello
1. ssl_session* 指令是针对服务端ssl的优化支持, 并不会对proxy的ssl客户端进行优化, 如要开启proxy的session id复用功能可以添加如下指令 `proxy_ssl_session_reuse on`(注意该指令是默认开启的) http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_session_reuse
2. OpenResty是可以实现动态upstream的, 详见:  https://github.com/openresty/lua-nginx-module#balancer_by_lua_block

在 2018年6月13日星期三 UTC+8下午8:21:45，Jimmy Yu写道：
1、我对这几个参数也不是特别熟悉，从网上资料看像是会对SSL Session复用有好处；
2、压测工具使用JMeter
3、根据您的建议，我修改了测试原型，采用如下形式，虽然也是传递变量，但是指向了固定的Upstream，压测发现CPU降下来了（即使我注释了keepalive效果也一样），但我的使用场景无法采用固定Upstream方式，因为我的后端服务器是变动的，不能每次调整都更改Upstream并Reload。
    upstream sg_ssl{
        server 192.168.0.2:18099;
        keepalive 32;
    }
        ssl_certificate /usr/local/openresty/nginx/cert/bundle.crt;
    ssl_certificate_key /usr/local/openresty/nginx/cert/ckey.key;

error_page 500 502 503 504 /50x.html;

        location /api/ {
            set $target "sgmain_ssl";
            proxy_pass https://$target;
        }
    }

在 2018年6月13日星期三 UTC+8下午4:48:29，Liu Lantao写道：

1 这几个参数目的是调节nginx对用户端的ssl，还是与proxy后端的ssl参数？貌似需要确认一下。

2 压测工具参数是什么？

3 需要 upstream keepalive 才可能能重用连接。
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

On Wed, Jun 13, 2018 at 11:03 AM Jimmy Yu <powerd...@gmail.com> wrote:
CentOS版本：7.3.1611
OpenResty版本：1.13.6.2
Windows版本：Win2016DataCenter（非AD，普通工作组）

Nginx采用https反向代理到后端Windows的IIS时导致lsass.exe占用CPU较高。验证发现采用变量形式CPU就很高，压测时占用50%左右，而采用注释的那一句直接proxypass到指定IP端口lsass.exe占用在5%-8%左右。

    server {
listen 443 ssl;

        ssl_certificate /usr/local/openresty/nginx/cert/bundle.crt;
    ssl_certificate_key /usr/local/openresty/nginx/cert/ckey.key;

error_page 500 502 503 504 /50x.html;

        location /api/ {
            set $target "192.168.0.2:18099";
            proxy_pass https://$target;
            #proxy_pass https://192.168.0.2:18099;
        }
    }

1、曾尝试使用ssl相关参数，但不起作用
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets on;
2、压测工具不走Nginx反向代理，直接压测IIS没问题，w3wp进程可以打满，lsass占用CPU极低
3、分析网络发现，走Nginx反向代理时，每条新的connection都不重用SSL/TLS的会话ID

--

--
Sent from Gmail Mobile

hongliang5316

Hello

1. 可以通过openssl客户端测试下你的proxy后端的服务是否支持ssl session resumption, 例如: echo | openssl s_client -connect www.baidu.com:443 -reconnect -no_ssl2 2> /dev/null | grep 'New\|Reuse'

另外可以压测下QPS 在`proxy_ssl_session_reuse off` 以及 `proxy_ssl_session_reuse on`的情况下是否有差距

2. 从你的配置上看proxy 的 keepalive是没有生效的因为nginx proxy默认采用的是http 1.0协议(不支持长链) 详见: http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

需要开启keepalive需要收到添加如下指令 proxy_http_version 1.1; proxy_set_header Connection ""; 我想这个也是性能损失的一大原因

在 2018年6月15日星期五 UTC+8下午4:14:52，Jimmy Yu写道：

1、我已经试过加proxy_ssl_session_reuse on参数，没效果
2、下午我用balancer_by_lua_block+ngx.balancer的方式验证了一遍，也是如此，感觉就是Nginx发出的请求没复用SSL的SessionID

    upstream balancer_ssl {
server 0.0.0.1;
balancer_by_lua_block {
local balancer = require "ngx.balancer"
local host = "10.80.0.23"
local port = 18099

local ok, err = balancer.set_current_peer(host, port)
if not ok then
ngx.log(ngx.ERR, "failed to set the current peer: ", err)
return ngx.exit(500)
end
}
keepalive 32;
}

...
server {
location /api/ {
...
            set $target "balancer_ssl";
            proxy_pass https://$target;
...

在 2018年6月15日星期五 UTC+8下午1:16:36，hongli...@gmail.com写道：
Hello
1. ssl_session* 指令是针对服务端ssl的优化支持, 并不会对proxy的ssl客户端进行优化, 如要开启proxy的session id复用功能可以添加如下指令 `proxy_ssl_session_reuse on`(注意该指令是默认开启的) http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_session_reuse
2. OpenResty是可以实现动态upstream的, 详见:  https://github.com/openresty/lua-nginx-module#balancer_by_lua_block

在 2018年6月13日星期三 UTC+8下午8:21:45，Jimmy Yu写道：
1、我对这几个参数也不是特别熟悉，从网上资料看像是会对SSL Session复用有好处；
2、压测工具使用JMeter
3、根据您的建议，我修改了测试原型，采用如下形式，虽然也是传递变量，但是指向了固定的Upstream，压测发现CPU降下来了（即使我注释了keepalive效果也一样），但我的使用场景无法采用固定Upstream方式，因为我的后端服务器是变动的，不能每次调整都更改Upstream并Reload。
    upstream sg_ssl{
        server 192.168.0.2:18099;
        keepalive 32;
    }
        ssl_certificate /usr/local/openresty/nginx/cert/bundle.crt;
    ssl_certificate_key /usr/local/openresty/nginx/cert/ckey.key;

error_page 500 502 503 504 /50x.html;

        location /api/ {
            set $target "sgmain_ssl";
            proxy_pass https://$target;
        }
    }

在 2018年6月13日星期三 UTC+8下午4:48:29，Liu Lantao写道：

1 这几个参数目的是调节nginx对用户端的ssl，还是与proxy后端的ssl参数？貌似需要确认一下。

2 压测工具参数是什么？

3 需要 upstream keepalive 才可能能重用连接。
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

On Wed, Jun 13, 2018 at 11:03 AM Jimmy Yu <powerd...@gmail.com> wrote:
CentOS版本：7.3.1611
OpenResty版本：1.13.6.2
Windows版本：Win2016DataCenter（非AD，普通工作组）

Nginx采用https反向代理到后端Windows的IIS时导致lsass.exe占用CPU较高。验证发现采用变量形式CPU就很高，压测时占用50%左右，而采用注释的那一句直接proxypass到指定IP端口lsass.exe占用在5%-8%左右。

    server {
listen 443 ssl;

        ssl_certificate /usr/local/openresty/nginx/cert/bundle.crt;
    ssl_certificate_key /usr/local/openresty/nginx/cert/ckey.key;

error_page 500 502 503 504 /50x.html;

        location /api/ {
            set $target "192.168.0.2:18099";
            proxy_pass https://$target;
            #proxy_pass https://192.168.0.2:18099;
        }
    }

1、曾尝试使用ssl相关参数，但不起作用
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets on;
2、压测工具不走Nginx反向代理，直接压测IIS没问题，w3wp进程可以打满，lsass占用CPU极低
3、分析网络发现，走Nginx反向代理时，每条新的connection都不重用SSL/TLS的会话ID

--

--
Sent from Gmail Mobile

powerdesigner

非常感谢您的及时回复。如您所言2，我虽在upstream设置了keepalive，但没有设置proxy_http_version和proxy_set_header两个参数信息，经设置后，后端lsass占用CPU的问题解决了！！困扰我两周的问题终于解决了，再次表示衷心感谢。

<hongli...@gmail.com> 于2018年6月15日周五下午6:22写道：

Hello
1. 可以通过openssl客户端测试下你的proxy后端的服务是否支持ssl session resumption, 例如: echo | openssl s_client -connect www.baidu.com:443 -reconnect -no_ssl2 2> /dev/null | grep 'New\|Reuse'
另外可以压测下QPS 在`proxy_ssl_session_reuse off` 以及 `proxy_ssl_session_reuse on`的情况下是否有差距
2. 从你的配置上看proxy 的 keepalive是没有生效的因为nginx proxy默认采用的是http 1.0协议(不支持长链) 详见: http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive
需要开启keepalive需要收到添加如下指令 proxy_http_version 1.1; proxy_set_header Connection ""; 我想这个也是性能损失的一大原因

在 2018年6月15日星期五 UTC+8下午4:14:52，Jimmy Yu写道：
1、我已经试过加proxy_ssl_session_reuse on参数，没效果
2、下午我用balancer_by_lua_block+ngx.balancer的方式验证了一遍，也是如此，感觉就是Nginx发出的请求没复用SSL的SessionID

    upstream balancer_ssl {
server 0.0.0.1;
balancer_by_lua_block {
local balancer = require "ngx.balancer"
local host = "10.80.0.23"
local port = 18099

local ok, err = balancer.set_current_peer(host, port)
if not ok then
ngx.log(ngx.ERR, "failed to set the current peer: ", err)
return ngx.exit(500)
end
}
keepalive 32;
}

...
server {
location /api/ {
...
            set $target "balancer_ssl";
            proxy_pass https://$target;
...

在 2018年6月15日星期五 UTC+8下午1:16:36，hongli...@gmail.com写道：
Hello
1. ssl_session* 指令是针对服务端ssl的优化支持, 并不会对proxy的ssl客户端进行优化, 如要开启proxy的session id复用功能可以添加如下指令 `proxy_ssl_session_reuse on`(注意该指令是默认开启的) http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_session_reuse
2. OpenResty是可以实现动态upstream的, 详见:  https://github.com/openresty/lua-nginx-module#balancer_by_lua_block

在 2018年6月13日星期三 UTC+8下午8:21:45，Jimmy Yu写道：
1、我对这几个参数也不是特别熟悉，从网上资料看像是会对SSL Session复用有好处；
2、压测工具使用JMeter
3、根据您的建议，我修改了测试原型，采用如下形式，虽然也是传递变量，但是指向了固定的Upstream，压测发现CPU降下来了（即使我注释了keepalive效果也一样），但我的使用场景无法采用固定Upstream方式，因为我的后端服务器是变动的，不能每次调整都更改Upstream并Reload。
    upstream sg_ssl{
        server 192.168.0.2:18099;
        keepalive 32;
    }
        ssl_certificate /usr/local/openresty/nginx/cert/bundle.crt;
    ssl_certificate_key /usr/local/openresty/nginx/cert/ckey.key;

error_page 500 502 503 504 /50x.html;

        location /api/ {
            set $target "sgmain_ssl";
            proxy_pass https://$target;
        }
    }

在 2018年6月13日星期三 UTC+8下午4:48:29，Liu Lantao写道：

1 这几个参数目的是调节nginx对用户端的ssl，还是与proxy后端的ssl参数？貌似需要确认一下。

2 压测工具参数是什么？

3 需要 upstream keepalive 才可能能重用连接。
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

On Wed, Jun 13, 2018 at 11:03 AM Jimmy Yu <powerd...@gmail.com> wrote:
CentOS版本：7.3.1611
OpenResty版本：1.13.6.2
Windows版本：Win2016DataCenter（非AD，普通工作组）

Nginx采用https反向代理到后端Windows的IIS时导致lsass.exe占用CPU较高。验证发现采用变量形式CPU就很高，压测时占用50%左右，而采用注释的那一句直接proxypass到指定IP端口lsass.exe占用在5%-8%左右。

    server {
listen 443 ssl;

        ssl_certificate /usr/local/openresty/nginx/cert/bundle.crt;
    ssl_certificate_key /usr/local/openresty/nginx/cert/ckey.key;

error_page 500 502 503 504 /50x.html;

        location /api/ {
            set $target "192.168.0.2:18099";
            proxy_pass https://$target;
            #proxy_pass https://192.168.0.2:18099;
        }
    }

1、曾尝试使用ssl相关参数，但不起作用
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets on;
2、压测工具不走Nginx反向代理，直接压测IIS没问题，w3wp进程可以打满，lsass占用CPU极低
3、分析网络发现，走Nginx反向代理时，每条新的connection都不重用SSL/TLS的会话ID

--

--
Sent from Gmail Mobile

--

powerdesigner

郁闷，上周压测一个Nginx没问题，在两个Nginx组成集群使用同一域名压测时，运行一段就几乎不发送请求了，然后过一段自动恢复。

在 2018年6月15日星期五 UTC+8下午6:40:35，Jimmy Yu写道：

非常感谢您的及时回复。如您所言2，我虽在upstream设置了keepalive，但没有设置proxy_http_version和proxy_set_header两个参数信息，经设置后，后端lsass占用CPU的问题解决了！！困扰我两周的问题终于解决了，再次表示衷心感谢。
<hongli...@gmail.com> 于2018年6月15日周五下午6:22写道：
Hello
1. 可以通过openssl客户端测试下你的proxy后端的服务是否支持ssl session resumption, 例如: echo | openssl s_client -connect www.baidu.com:443 -reconnect -no_ssl2 2> /dev/null | grep 'New\|Reuse'
另外可以压测下QPS 在`proxy_ssl_session_reuse off` 以及 `proxy_ssl_session_reuse on`的情况下是否有差距
2. 从你的配置上看proxy 的 keepalive是没有生效的因为nginx proxy默认采用的是http 1.0协议(不支持长链) 详见: http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive
需要开启keepalive需要收到添加如下指令 proxy_http_version 1.1; proxy_set_header Connection ""; 我想这个也是性能损失的一大原因

在 2018年6月15日星期五 UTC+8下午4:14:52，Jimmy Yu写道：
1、我已经试过加proxy_ssl_session_reuse on参数，没效果
2、下午我用balancer_by_lua_block+ngx.balancer的方式验证了一遍，也是如此，感觉就是Nginx发出的请求没复用SSL的SessionID

    upstream balancer_ssl {
server 0.0.0.1;
balancer_by_lua_block {
local balancer = require "ngx.balancer"
local host = "10.80.0.23"
local port = 18099

local ok, err = balancer.set_current_peer(host, port)
if not ok then
ngx.log(ngx.ERR, "failed to set the current peer: ", err)
return ngx.exit(500)
end
}
keepalive 32;
}

...
server {
location /api/ {
...
            set $target "balancer_ssl";
            proxy_pass https://$target;
...

在 2018年6月15日星期五 UTC+8下午1:16:36，hongli...@gmail.com写道：
Hello
1. ssl_session* 指令是针对服务端ssl的优化支持, 并不会对proxy的ssl客户端进行优化, 如要开启proxy的session id复用功能可以添加如下指令 `proxy_ssl_session_reuse on`(注意该指令是默认开启的) http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ssl_session_reuse
2. OpenResty是可以实现动态upstream的, 详见:  https://github.com/openresty/lua-nginx-module#balancer_by_lua_block

在 2018年6月13日星期三 UTC+8下午8:21:45，Jimmy Yu写道：
1、我对这几个参数也不是特别熟悉，从网上资料看像是会对SSL Session复用有好处；
2、压测工具使用JMeter
3、根据您的建议，我修改了测试原型，采用如下形式，虽然也是传递变量，但是指向了固定的Upstream，压测发现CPU降下来了（即使我注释了keepalive效果也一样），但我的使用场景无法采用固定Upstream方式，因为我的后端服务器是变动的，不能每次调整都更改Upstream并Reload。
    upstream sg_ssl{
        server 192.168.0.2:18099;
        keepalive 32;
    }
        ssl_certificate /usr/local/openresty/nginx/cert/bundle.crt;
    ssl_certificate_key /usr/local/openresty/nginx/cert/ckey.key;

error_page 500 502 503 504 /50x.html;

        location /api/ {
            set $target "sgmain_ssl";
            proxy_pass https://$target;
        }
    }

在 2018年6月13日星期三 UTC+8下午4:48:29，Liu Lantao写道：

1 这几个参数目的是调节nginx对用户端的ssl，还是与proxy后端的ssl参数？貌似需要确认一下。

2 压测工具参数是什么？

3 需要 upstream keepalive 才可能能重用连接。
http://nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive

On Wed, Jun 13, 2018 at 11:03 AM Jimmy Yu <powerd...@gmail.com> wrote:
CentOS版本：7.3.1611
OpenResty版本：1.13.6.2
Windows版本：Win2016DataCenter（非AD，普通工作组）

Nginx采用https反向代理到后端Windows的IIS时导致lsass.exe占用CPU较高。验证发现采用变量形式CPU就很高，压测时占用50%左右，而采用注释的那一句直接proxypass到指定IP端口lsass.exe占用在5%-8%左右。

    server {
listen 443 ssl;

        ssl_certificate /usr/local/openresty/nginx/cert/bundle.crt;
    ssl_certificate_key /usr/local/openresty/nginx/cert/ckey.key;

error_page 500 502 503 504 /50x.html;

        location /api/ {
            set $target "192.168.0.2:18099";
            proxy_pass https://$target;
            #proxy_pass https://192.168.0.2:18099;
        }
    }

1、曾尝试使用ssl相关参数，但不起作用
ssl_session_timeout 10m;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets on;
2、压测工具不走Nginx反向代理，直接压测IIS没问题，w3wp进程可以打满，lsass占用CPU极低
3、分析网络发现，走Nginx反向代理时，每条新的connection都不重用SSL/TLS的会话ID

--

--
Sent from Gmail Mobile

--