배경
우리는 7개의 로드 계층을 갖고 있으며 24U 64G 메모리를 갖춘 5개의 물리적 머신을 사용합니다. Branch nginx는 https 암호화, 암호 해독 및 Proxy_pass를 수행합니다. 매일 출퇴근하는 동안 5대 기계의 CPU는 기본적으로 약 50% 수준이며 이는 컴퓨팅 유형으로 간주됩니다.
최적화 방법: keepalive, TLS1.2 암호화 알고리즘 최적화(참조: 1, 2) 등은 거의 효과가 없습니다.
서버가 이를 어떻게 지원하든 핵심은 클라이언트가 계속 유지하지 않으면 망할 것이라는 점입니다.
테스트 프로세스
nginx -V:
버전: openresty/1.9.7.3
gcc 4.8.5 20150623(Red Hat 4.8.5-4)(GCC)에 의해 구축
OpenSSL 1.0.1e-fips로 구축, 2013년 2월 11일
TLS SNI 지원 활성화
–with-http_v2_module
Apache의 ab 스트레스 테스트 도구: yum 설치
그림:
흐름도를 넣으면 이해가 될 것입니다.
아래 그림은 ab와 boom을 사용할 때를 보여줍니다.
이때 ab, boom 모두 -k를 사용합니다. 어떻게 연주해도 측정치나 시간은 대략 이 수준입니다.
예를 들어, 다음 명령은 기본적으로 실행하는 데 30분이 걸립니다.
boom -c 1000 -n 1000000 -allow-insecure https://172.16.9.234/5k.jpg
ab -c 1000 -n 1000000 -khttps://172.16.9.234/5k.jpg
매개변수가 http2로 변경되지 않은 경우:
h2load -c 1000 -n 1000000 -m1 https://172.16.9.234/5k.jpg
h2load 실행 결과는 다음과 같습니다.
다음 그림은 h2load 테스트를 보여줍니다. http2:
기가비트 네트워크 카드, 아웃바운드 트래픽이 완전히 로드되었습니다.
결론
다음 결론은 반복적으로 테스트되었으며 내 의견만을 나타냅니다. toontong.