通过https/SSL访问NGINX/PHP-FPM时速度极慢

前端之家收集整理的这篇文章主要介绍了通过https/SSL访问NGINX/PHP-FPM时速度极慢前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

从一周前开始,我开始注意到我的webapp的糟糕表现.

我的应用程序在Amazon EC2 m1.large实例上提供.

仅4-5kb的静态文件通常需要超过10秒才能接收.这会间歇性地发生,但对于每个页面加载,我可以预期特定资源的至少1或两个巨大的等待时间.

从检查Firebug很明显,持有是在请求的“等待”部分. (DNS /连接/发送和接收总是很好)

不幸的是,我还没有在这里发布图像所需的声誉,或者我愿意.

更糟糕的是,当页面请求许多静态资源(如Images)时,几乎每个请求似乎都会出现此问题.

玩过我的Nginx和@L_301_1@-FPM配置会在过去一周左右,直到今天我才注意到问题似乎只有在通过HTTPS访问服务器时才存在.

使用ab命令测试性能时可以看到这一点.

HTTPS:

ab -c 100 -n 3000 https://www.mydomain.com/

    Server Port:            443
SSL/TLS Protocol:       TLSv1,RC4-SHA,2048,128

Document Path:          /
Document Length:        13367 bytes

Concurrency Level:      100
Time taken for tests:   12.122 seconds
Complete requests:      3000
Failed requests:        0
Write errors:           0
Total transferred:      41205000 bytes
HTML transferred:       40101000 bytes
Requests per second:    247.48 [#/sec] (mean)
Time per request:       404.067 [ms] (mean)
Time per request:       4.041 [ms] (mean,across all concurrent requests)
Transfer rate:          3319.52 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       13  219  91.2    216     577
Processing:    18  178  83.5    166     562
Waiting:       10  168  80.5    156     549
Total:         60  397 124.9    386     809

HTTP:

 ab -c 100 -n 3000 http://www.mydomain.com/

    Server Port:            80

    Document Path:          /
    Document Length:        184 bytes

    Concurrency Level:      100
    Time taken for tests:   0.468 seconds
    Complete requests:      3000
    Failed requests:        0
    Write errors:           0
    Non-2xx responses:      3000
    Total transferred:      1431000 bytes
    HTML transferred:       552000 bytes
    Requests per second:    6404.06 [#/sec] (mean)
    Time per request:       15.615 [ms] (mean)
    Time per request:       0.156 [ms] (mean,across all concurrent requests)
    Transfer rate:          2983.14 [Kbytes/sec] received

    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        3    7   2.2      8      11
    Processing:     2    8   2.4      7      18
    Waiting:        1    6   2.0      6      16
    Total:         11   15   1.4     15      28

在诊断这些问题时我很缺乏经验,而且我很可能误读了上述工具的输出.无论如何,尽管谷歌搜索量很大,我仍然不知道从哪里开始.

我的Nginx.conf的相关部分:

 #SSL certs
 ssl on;
 ssl_certificate /etc/ssl/certs/mycert.crt;
 ssl_certificate_key /etc/ssl/certs/mycert.key;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
 ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM;
 ssl_session_cache   shared:SSL:10m;
 ssl_session_timeout 10m;                          
 ssl_prefer_server_ciphers   on;

首先,我想知道我是否看起来是正确的轨道,我的断言是SSL / HTTPS导致问题.其次,对于如何纠正它有什么建议.

直到最近,完全相同的配置完美无缺,所以我真的不确定发生了什么.

提前谢谢了.

最佳答案
ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM;

您需要删除该条目

ECDHE-RSA-AES256-SHA384

 

这使得椭圆曲线Diffie-Helman Ephemeral密码能够替换它

!kEDH

 除非您需要完美的前向保密,否则这是不必要的,并且是您在请求中看到的长时间延迟的原因.对于大多数应用,HIGH密码条目应该是完全合理的.

*快速编辑:您可以使用openssl命令行实用程序查看正在协商的密码:

openssl s_client -host HOSTNAME -port 443

用您正在查看的服务器的IP或域名替换主机名.如果在这些更改之前在“密码”行中看到“DHE-RSA-AES256-SHA”,则很可能是这个问题.

猜你在找的Nginx相关文章