我怎样才能优化HAProxy与SSL终止到Ubuntu的Nginx后端?
设置工作正常,路由正常。 但是,当我使用HAProxy执行SSL终止时,会有巨大的性能下降(下面的testing)。 关键是4096位的rsa。 HAProxy强制HTTPS进行validation,然后终止SSL,并将HTTP传输到后端Nginx服务器。 Nginx的服务器是相同的,并提供多个静态页面,即192.168.1.xx / page1.html,192.168.1.xx / page2.html等(我包括NodeJS为我的系统的完整性,但只增加了<1毫秒的延迟。可以忽略。)
这里是设置,configuration和当前的testing。 每个虚拟机(VM)运行Ubuntu 14.04,并且可以具有可变数量的CPU和RAM。
这里是HAProxyconfiguration:
global maxconn 40000 tune.ssl.default-dh-param 2048 log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats socket /run/haproxy/admin.sock mode 660 level admin stats timeout 30s user haproxy group haproxy # Default SSL material locations ca-base /etc/ssl/certs crt-base /etc/ssl/private # Default ciphers to use on SSL-enabled listening sockets. # For more information, see ciphers(1SSL). This list is from: # https://hynek.me/articles/harding-your-web-servers-ssl-ciphers/ ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS ssl-default-bind-options no-sslv3 defaults option forwardfor option http-server-close stats enable stats uri /stats stats realm Haproxy\ Statistics stats auth user:password log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000 errorfile 400 /etc/haproxy/errors/400.http errorfile 403 /etc/haproxy/errors/403.http errorfile 408 /etc/haproxy/errors/408.http errorfile 500 /etc/haproxy/errors/500.http errorfile 502 /etc/haproxy/errors/502.http errorfile 503 /etc/haproxy/errors/503.http errorfile 504 /etc/haproxy/errors/504.http frontend www-http bind 192.168.1.10:80 reqadd X-Forwarded-Proto:\ http default_backend www-backend frontend www-https bind 192.168.1.10:443 ssl crt /etc/ssl/private/company.pem reqadd X-Forwarded-Proto:\ https use_backend node-backend if { path_beg /socket.io } default_backend www-backend backend www-backend redirect scheme https if !{ ssl_fc } server www-1 192.168.1.20:80 check server www-2 192.168.1.21:80 check server www-3 192.168.1.22:80 check backend node-backend server node-1 192.168.1.30:8888 check
这里是ApacheBench(ab)testing到Nginx服务器之一:
$ ab -c 200 -n 10000 http://192.168.1.20/ Server Software: nginx/1.4.6 Server Hostname: 192.168.1.20 Server Port: 80 Document Path: / Document Length: 3130 bytes Concurrency Level: 200 Time taken for tests: 2.257 seconds Complete requests: 10000 Failed requests: 0 Total transferred: 33720000 bytes HTML transferred: 31300000 bytes Requests per second: 4430.21 [#/sec] (mean) Time per request: 45.145 [ms] (mean) Time per request: 0.226 [ms] (mean, across all concurrent requests) Transfer rate: 14588.55 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 4 27 104.3 16 1187 Processing: 4 18 8.2 16 358 Waiting: 3 18 7.9 16 334 Total: 9 45 105.8 32 1225 Percentage of the requests served within a certain time (ms) 50% 32 66% 41 75% 43 80% 44 90% 49 95% 52 98% 55 99% 57 100% 1225 (longest request)
这里是ApacheBench(ab)testingHAProxy与http:
$ ab -c 200 -n 10000 http://192.168.1.10/ Server Software: nginx/1.4.6 Server Hostname: 192.168.1.10 Server Port: 80 Document Path: / Document Length: 3130 bytes Concurrency Level: 200 Time taken for tests: 1.918 seconds Complete requests: 10000 Failed requests: 0 Total transferred: 33720000 bytes HTML transferred: 31300000 bytes Requests per second: 5215.09 [#/sec] (mean) Time per request: 38.350 [ms] (mean) Time per request: 0.192 [ms] (mean, across all concurrent requests) Transfer rate: 17173.14 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 3 18 3.5 18 32 Processing: 7 20 3.5 19 36 Waiting: 7 20 3.4 19 36 Total: 15 38 4.2 37 57 Percentage of the requests served within a certain time (ms) 50% 37 66% 38 75% 39 80% 40 90% 44 95% 46 98% 50 99% 51 100% 57 (longest request)
这里是ApacheBench(ab)testingHAProxy与https:
$ ab -c 200 -n 10000 https://192.168.1.10/ Server Software: nginx/1.4.6 Server Hostname: 192.168.1.10 Server Port: 443 SSL/TLS Protocol: TLSv1,DHE-RSA-AES256-SHA,2048,256 Document Path: / Document Length: 3130 bytes Concurrency Level: 200 Time taken for tests: 566.303 seconds Complete requests: 10000 Failed requests: 0 Total transferred: 33720000 bytes HTML transferred: 31300000 bytes Requests per second: 17.66 [#/sec] (mean) Time per request: 11326.069 [ms] (mean) Time per request: 56.630 [ms] (mean, across all concurrent requests) Transfer rate: 58.15 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 483 8982 3326.6 11090 14031 Processing: 16 2255 3313.0 43 11399 Waiting: 14 2186 3253.3 35 11252 Total: 5648 11237 879.1 11212 22732 Percentage of the requests served within a certain time (ms) 50% 11212 66% 11274 75% 11308 80% 11321 90% 11395 95% 11641 98% 11847 99% 14063 100% 22732 (longest request)
这是HAProxy VM上的OpenSSLtesting。
$ openssl speed rsa sign verify sign/s verify/s rsa 512 bits 0.000081s 0.000006s 12314.6 179042.8 rsa 1024 bits 0.000277s 0.000017s 3603.7 60563.8 rsa 2048 bits 0.001852s 0.000058s 539.8 17231.3 rsa 4096 bits 0.013793s 0.000221s 72.5 4517.4
所以,我看的方式是HAProxy不能胜过72.5 sign / s,4517.4 verify / s的openssl速度testing。 但是,SSL终止的HAProxy正在执行大约17个请求/秒。 当然,我们可以通过一个较小的键来提高整体性能,但是这并不能解决从openssl速度testing到HAProxy〜4.5x速度增加的问题(如果存在问题的话)。
那么,考虑到这些信息,是否有一个最佳的HAProxyconfiguration可以提高性能? 我是否缺less一些一般的东西,例如:当用户第一次访问一个页面时,他们只需要“签名”一次,并且所有并发的请求都只是“validation”。 如果是这样的话,那么ABtesting就没有适当的测量(如果我错了,纠正我)。 而且,要发生这种情况,用户是否必须访问相同的Nginx服务器? 如果是这样,那是否需要坚持会议?
在试图回答我自己的问题时,我尝试从这篇文章中添加粘性会话: HAProxy使用SSL和粘性会话,并使用Siege来testing多个URL。 但是,performance还没有提升。
$ siege -c 100 -r 10 -b -f urls.txt Transactions: 1000 hits Availability: 100.00 % Elapsed time: 22.56 secs Data transferred: 2.84 MB Response time: 2.17 secs Transaction rate: 44.33 trans/sec Throughput: 0.13 MB/sec Concurrency: 96.06 Successful transactions: 1000 Failed transactions: 0 Longest transaction: 8.96 Shortest transaction: 0.16
其中urls.txt是
URL=https://192.168.1.10/ $(URL) $(URL)page1.html $(URL)page2.html
那么,我坚持这样的performance吗? 有些地方提到类似的请求率为〜75 ms /请求4096位密钥。 https://certsimple.com/blog/measuring-ssl-rsa-keys
或者,我的HAProxyconfiguration不良,正在处理SSL 2x的地方? ServerFault:/ questions / 574582 / nginx-ssl-termination-slow
有一点需要考虑的是,许多HTTP客户端(包括浏览器)试图通过几个HTTP请求分摊SSL握手的成本。 也就是说,他们build立到服务器的一个TCP连接,执行SSL握手,然后重复使用该TCP连接(使用SSL会话)进行多个请求/响应,而不是每个请求执行一次SSL握手。
要在您的设置中启用这种场景/testing,您可以为前端 HTTP请求包含-k命令行选项。
另一个考虑是你使用option http-server-close HAproxy设置。 这告诉haproxy根据前端HTTP请求build立一个新的后端TCP连接; 这可以添加自己的40-100毫秒(如果不是更多),这取决于后端networking。 如果您允许HAproxy保持打开后端TCP连接,那么也可能会减lessab报告的每个请求延迟。
根据您预期的SSL会话的数量,也可以增加SSL会话caching的内存分配(HAproxy的tune.ssl.cachesize设置,可能与tune.ssl.lifetime结合使用以增加caching超时,从而增加会话caching重用的可能性)将允许更多的恢复SSL会话(以及更快/更less计算密集的SSL握手)。
但是我认为,当使用keep-alive( -k )时,由ab报告的数字将更好地显示重用相同SSL会话(通过相同的TCP连接)的许多HTTP请求的有效性。
希望这可以帮助!
比较苹果和苹果。
您的基准openssl speed rsa可能不会衡量DHE时间,因为它不使用临时密钥。 这意味着你testing一个不太安全的algorithm,而不是DHEalgorithm。 后者是较慢的,另一方面它提供了完美的前向保密(PFS)。
但是DHE相当陈旧,效率低下,现代浏览器通常使用更好的ECDHE(甚至ECDSA)。
我想你应该设置你的ab基准来执行ECDHE-RSA-AES128-SHA256。 我认为你应该编程你的openssl基准testing,以使用openssl s_client -cipher ECDHE-RSA-AES128-SHA256 (而不是简单的openssl speed )循环。