NGINX HTTPS 역방향 프록시 - 빠른 TTFB이지만 동시성이 낮습니다.

NGINX HTTPS 역방향 프록시 - 빠른 TTFB이지만 동시성이 낮습니다.

NGINX(SSL) => VARNISH(CACHE) => APACHE/PHP를 실행하는 애플리케이션이 있습니다.

달리기ab 벤치마크, EC2 t2.small 인스턴스를 통해 (HTTP를 통해) 광택 레이어에서 초당 30,000개 이상의 요청을 달성할 수 있습니다. 그러나 NGINX(HTTPS)를 통해 테스트를 실행하면 초당 160개의 요청만 푸시할 수 있습니다(공개 웹에서 TTFB의 경우 평균 43ms).

@ nginx.conf

user  nginx;
worker_processes  auto;

worker_rlimit_nofile 65535;

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

pid        /var/run/nginx.pid;


events {
    worker_connections  16024;
        multi_accept on;
}

http 수준에서는 다음과 같습니다.

sendfile        on;
tcp_nopush     on;

keepalive_timeout  10;


ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;

@도메인.conf

server {
        listen 443 ssl;

        server_name xyz.com;
        ssl_certificate /home/st/ssl3/xyz.crt;
        ssl_certificate_key /home/xyz/ssl3/xyz.key;

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5;

        ssl_session_tickets on;

        location / {

                proxy_buffers 8 8k;
                proxy_buffer_size 2k;


            proxy_pass http://127.0.0.1:79;
            proxy_set_header X-Real-IP  $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto https;
            proxy_set_header X-Forwarded-Port 443;
            proxy_set_header Host $host;

                proxy_redirect off;

        }

    add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";
}

Apache에 대한 벤치마크는 다음과 같습니다.

내부 => @APACHE:

Concurrency Level:      10
Time taken for tests:   0.694 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1002
Keep-Alive requests:    996
Total transferred:      705122 bytes
HTML transferred:       401802 bytes
Requests per second:    1440.93 [#/sec] (mean)
Time per request:       6.940 [ms] (mean)
Time per request:       0.694 [ms] (mean, across all concurrent requests)
Transfer rate: 992.22 [Kbytes/sec] received

다음은 Varnish에 대한 벤치마크입니다(이전에는 20-30k로 실행 중이었습니다. CPU 주기를 모두 소모했으며 평균 ATM은 4-8k rps입니다).

내부 => @VARNISH => @APACHE:

Concurrency Level:      10
Time taken for tests:   0.232 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      23439800 bytes
HTML transferred:       23039412 bytes
Requests per second:    4310.16 [#/sec] (mean)
Time per request:       2.320 [ms] (mean)
Time per request:       0.232 [ms] (mean, across all concurrent requests)
Transfer rate:          98661.39 [Kbytes/sec] received

다음은 NGINX에 대한 벤치마크입니다.HTTP

내부 => @NGINX[HTTP] => @VARNISH => @APACHE:

Concurrency Level:      10
Time taken for tests:   0.082 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1001
Keep-Alive requests:    1000
Total transferred:      382382 bytes
HTML transferred:       184184 bytes
Requests per second:    12137.98 [#/sec] (mean)
Time per request:       0.824 [ms] (mean)
Time per request:       0.082 [ms] (mean, across all concurrent requests)
Transfer rate:          4532.57 [Kbytes/sec] received

다음은 NGINX에 대한 벤치마크입니다.HTTPS

내부 => @NGINX[HTTPS=>HTTP] => @VARNISH => @APACHE:

Concurrency Level:      10
Time taken for tests:   7.029 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Keep-Alive requests:    0
Total transferred:      663000 bytes
HTML transferred:       401000 bytes
Requests per second:    142.27 [#/sec] (mean)
Time per request:       70.288 [ms] (mean)
Time per request:       7.029 [ms] (mean, across all concurrent requests)
Transfer rate:          92.12 [Kbytes/sec] received

답변1

글쎄요, 귀하가 제공한(그리고 제공하지 않은) 정보로 추측할 수 있을 뿐입니다. 그러나 인스턴스 유형(t2는 버스트 가능한 티켓 기반 성능을 가지고 있으며 티켓이 부족할 때 코어의 약 20%를 얻습니다. 벤치마크를 수행하기에는 좋은 인스턴스가 아닙니다)와 테스트를 위한 사용 ab(btw. 작성할 때) 으로 판단합니다. 'AB 테스트'라고 하면 가장 먼저 떠오르는 것은이것) 당신의 성과는 예상과 거의 일치한다고 말하고 싶습니다.

SSL 또는 TLS 세션을 시작할 때 가장 성능 집약적인 작업은 데이터 암호화/암호 해독이 아니라 키 교환입니다. SSL 세션 캐싱을 사용하지 않으므로 ab모든 연결에서 키 교환을 수행해야 합니다.

실제로 사용된 암호/kex/인증 제품군에 따라(알 수 없음, ab제공된 출력 없음) CPU에 상당한 작업이 될 수 있습니다. 그리고 양쪽 끝이 동일한 시스템에 있기 때문에 연결당 CPU 요구 사항이 두 배로 늘어납니다(간단하지만 여기서는 충분합니다).

실제 사용에서 연결 유지는 더 나은 성능을 얻는 데 도움이 될 수 있습니다(클라이언트에 따라 다르며 일반 브라우저에서 사용합니다. 시도해 보세요 ab -k). 그리고 언급한 SSL 세션 캐싱을 통해 더 나은 성능을 얻을 수 있습니다(역시 클라이언트에 따라 다르며 일반 브라우저에서는 이를 지원합니다).

성과를 향상시키는 데 도움이 되는 몇 가지 다른 방법이 있습니다. 물론 더 나은 하드웨어를 얻을 수도 있습니다. 키 크기를 최적화할 수 있습니다(앱에 필요한 보호 수준에 따라 다름). 일반적으로 키가 작을수록 작업 비용이 더 저렴합니다. 다른 컴퓨터에서 테스트하면 겉보기 성능이 향상될 수도 있고 향상되지 않을 수도 있습니다. 그리고 다른 OpenSSL 빌드나 다른 SSL 라이브러리를 모두 사용하면 더 나은 성능을 제공할 수도 있습니다.

참고로 그냥 보시면 됩니다이 종이인텔에 의해. 고도로 최적화된 시스템(및 일부 최적화된 소프트웨어)의 성능을 비교합니다. 사용 가능한 컴퓨팅 성능이 1/30 미만이라고 생각하세요(티켓이 부족한 경우 1/150만큼 낮을 수 있음).

하지만 고성능 SSL이 필요한 경우 이미 EC2를 사용하고 있으므로 Amazon ELB를 사용하여 SSL 종료를 수행하는 것을 고려해 볼 가치가 있습니다.

편집: 예를 들어아파치 JMeterSSL 컨텍스트 캐싱을 사용합니다.httperf그것도 마찬가지다. 특히 JMeter가 실제와 같은 로드를 시뮬레이션하는 데 능숙하다고 생각합니다. 그러나 이 httperf 세션 캐싱 방식의 경우 가장 잘 작동할 수 있습니다.

-k아직 사용되지 않았기 때문에 아무런 차이가 없는 것일 수도 있습니다. 동시성 설정에 따라 다르며 (적어도 내 컴퓨터에서는) URL에도 의존하는 것 같습니다. URL에서 둘 이상의 IP를 가리키는 도메인 이름을 사용하는 경우 Keepalives를 사용하지 않습니다(이유는 묻지 마세요).

대규모에 대한 귀하의 인식에 따라 다르지만 이 작은 인스턴스에서는 버스트에서 초당 약 500개 이상의 연결을 얻을 것으로 예상하지 않으며 지속 속도는 250cps 이하입니다.

광택 일반 텍스트 http를 nginx ssl과 비교하는 것은 배와 사과를 비교하는 것입니다. 또는 하드웨어 요구 사항 측면에서 블루베리를 수박과 비교합니다.

참고용으로 다시 한 번 말씀드리겠습니다( Keep-Alive requests: 100라인에 주목하세요).

없이-k

Concurrency Level:      1
Time taken for tests:   0.431 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      399300 bytes
HTML transferred:       381200 bytes
Requests per second:    232.26 [#/sec] (mean)
Time per request:       4.305 [ms] (mean)
Time per request:       4.305 [ms] (mean, across all concurrent requests)
Transfer rate:          905.69 [Kbytes/sec] received

와 함께-k

Concurrency Level:      1
Time taken for tests:   0.131 seconds
Complete requests:      100
Failed requests:        0
Keep-Alive requests:    100
Total transferred:      402892 bytes
HTML transferred:       381200 bytes
Requests per second:    762.11 [#/sec] (mean)
Time per request:       1.312 [ms] (mean)
Time per request:       1.312 [ms] (mean, across all concurrent requests)
Transfer rate:          2998.53 [Kbytes/sec] received

Edit2: 글쎄요, 메모리에서 직접 콘텐츠를 제공하는 것(Varnish가 하는 일)이 가능한 한 쉽다는 것을 이해해야 합니다. 헤더를 구문 분석하고, 메모리에서 콘텐츠를 찾아 내뱉습니다. 그리고 Varnish는 이것에 탁월합니다.

암호화된 연결을 설정하는 것은 완전히 다른 수준입니다. 따라서 nginx를 추가하면 SSL 핸드셰이크(키 교환, 인증)와 암호화를 수행해야 하며 여기에는 훨씬 더 많은 리소스가 필요합니다. 그런 다음 헤더를 구문 분석합니다. 그런 다음 Varnish에 대한 또 다른 TCP 연결을 생성해야 합니다.

또, 앞서 언급한 내용에서인텔 종이, 그들은 28개의 코어를 가지고 있으며 OpenSSL을 약간 조정하여 38k HTTPS cps(Varnish 성능보다 약간 더 높음)를 수행했습니다. 코어의 약 1/5을 가지고 있으며 가상 이웃의 영향을 받습니다.

인용Amazon EC2 인스턴스 목록:

예를 들어 t2.small 인스턴스는 시간당 12 CPU 크레딧의 속도로 지속적으로 크레딧을 받습니다. 이 기능은 CPU 코어의 20%에 해당하는 기본 성능을 제공합니다.

그리고 또 다른종이nginx 자체에서:

결과 요약 단일 가상화된 Intel 코어는 일반적으로 최신 암호화 암호를 사용하여 초당 최대 350개의 전체 2048비트 SSL 핸드셰이크 작업을 수행할 수 있습니다. 이는 코어당 초당 수백 명의 신규 서비스 사용자에 해당합니다.

관련 정보