ssl proxys https web server is very slow

[Mark Moseley]

On Fri, Jun 20, 2014 at 5:20 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Fri, Jun 20, 2014 at 10:51:38AM +0200, Yifeng Wang wrote:
>
> > Hi, It's my first time using NGINX to proxy other web servers. I set a
> > variable in location, this variable may be gotten in cookie or args. if
> > I use it directly likes "proxy_pass https://$nodeIp2;", it will get the
> > response for a long time. but if I hardcode likes "proxy_pass
> > https://147.128.22.152:8443" it works normally. Do I need to set more
> > cofiguration parameters to solve this problem.Below is the segment of my
> > windows https configuration.
> >
> > http {
> >     ...
> >     server {
> >        listen       443 ssl;
> >        server_name  localhost;
> >
> >        ssl_certificate      server.crt;
> >        ssl_certificate_key  server.key;
> >
> >        location /pau6000lct/ {
> >             set $nodeIp 147.128.22.152:8443;
> >             proxy_pass https://$nodeIp;
>
> Use of variables in the proxy_pass, in particular, implies that
> SSL sessions will not be reused (as upstream address is not known
> in advance, and there is no associated storage for an SSL
> session).  This means that each connection will have to do full
> SSL handshake, and this is likely the reason for the performance
> problems you see.
>
> Solution is to use proxy_pass without variables, or use
> preconfigured upstream{} blocks instead of ip addresses if you
> have to use variables.
>

So to prevent the heart attack I almost just had, can you confirm how I
interpret that last statement:

If you define your upstream using "upstream upstream_name etc" and then use
a variable indicating the name of the upstream in proxy_pass statement,
that will *not* cause SSL sessions to not be reused. I.e. proxy_pass with a
variable indicating upstream would not cause a performance issue.

Is that correct?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20140620/1ec03d19/attachment.html>