웹 서버 전쟁. 2부 – 현실적인 HTTPS 시나리오:

우리는 방법론에 대해 이야기했습니다. 첫 번째 부분 이 기사에서는 HTTPS를 테스트하지만 보다 현실적인 시나리오에서 테스트합니다. 테스트를 위해 Let's Encrypt 인증서를 획득하고 Brotli 압축을 11로 활성화했습니다.

이번에는 서버를 VDS에 배포하거나 표준 프로세서가 있는 호스트에 가상 머신으로 배포하는 시나리오를 재현해 보겠습니다. 이를 위해 다음과 같이 한도가 설정되었습니다.

• 25% - ~ 1350MHz의 주파수에 해당
• 35% -1890MHz
• 41% - 2214MHz
• 65% - 3510MHz

일회성 접속 횟수가 500회에서 1, 3, 5, 7, 9회로 줄어들었고,

결과 :

지연:

HTTPD 도구는 각 개별 요청에 대해 새 사용자를 생성하므로 TTFB는 별도의 테스트로 특별히 포함되었습니다. 이 테스트는 사용자가 여전히 몇 페이지를 클릭하고 실제로는 TTFP가 주요 역할을 하기 때문에 현실과는 상당히 동떨어져 있습니다.

일반적으로 IIS 가상 머신을 처음 시작한 후 첫 번째 요청은 평균 120ms가 소요됩니다.

모든 후속 요청에는 1.5ms의 TTFP가 표시됩니다. 이 점에서 Apache와 Nginx는 뒤쳐져 있습니다. 개인적으로 저자는 이 테스트가 가장 드러나는 테스트라고 생각하며 이를 토대로 승자를 선택할 것입니다.
IIS는 이미 압축된 정적 콘텐츠를 캐시하고 액세스할 때마다 압축하지 않으므로 결과는 놀라운 일이 아닙니다.

클라이언트당 소요 시간

성능을 평가하려면 1개의 단일 연결을 사용한 테스트로 충분합니다.
예를 들어 IIS는 5000초 만에 40명의 사용자에 대한 테스트를 완료했습니다. 이는 초당 123개의 요청입니다.

아래 그래프는 사이트 콘텐츠가 완전히 전송될 때까지의 시간을 보여줍니다. 이는 주어진 시간에 완료된 요청의 비율입니다. 우리의 경우 모든 요청의 80%가 IIS에서 8ms, Apache 및 Nginx에서 4.5ms 내에 처리되었으며, Apache 및 Nginx에서 모든 요청의 8%가 최대 98밀리초 이내에 완료되었습니다.

5000개의 요청이 처리된 시간:

5000개의 요청이 처리된 시간:

3.5GHz CPU와 8개 코어를 갖춘 가상 머신이 있다면 원하는 것을 선택하세요. 이 테스트에서는 모든 웹 서버가 매우 유사합니다. 아래에서는 각 호스트에 대해 어떤 웹 서버를 선택할 것인지에 대해 설명하겠습니다.

좀 더 현실적인 상황에서는 모든 웹 서버가 정면으로 맞서게 됩니다.

처리량 :

지연과 동시 연결 수의 그래프입니다. 부드럽고 낮을수록 좋습니다. 마지막 2%는 읽을 수 없기 때문에 차트에서 제거되었습니다.

이제 서버가 가상 호스팅에서 호스팅되는 옵션을 고려해 보겠습니다. 4GHz에서는 코어 2.2개, 1.8GHz에서는 코어 XNUMX개를 사용하겠습니다.

확장 방법

진공 XNUMX극관, XNUMX극관 등의 전류-전압 특성이 어떤지 본 적이 있다면 이 그래프가 익숙할 것입니다. 이것이 바로 우리가 포착하려고 하는 것입니다. 바로 포화입니다. 한계는 아무리 많은 코어를 던져도 성능 향상이 눈에 띄지 않는 경우입니다.

이전에는 모든 요청에 ​​대해 가장 짧은 지연 시간으로 요청의 98%를 처리하고 곡선을 최대한 평평하게 유지하는 것이 전체 과제였습니다. 이제 또 다른 곡선을 구성하여 각 서버에 대한 최적의 작동 지점을 찾습니다.

이를 위해 RPR(초당 요청 수) 표시기를 살펴보겠습니다. 가로는 빈도, 세로는 초당 처리되는 요청 수, 선은 코어 수입니다.

Nginx가 요청을 차례로 얼마나 잘 처리하는지에 대한 상관 관계를 보여줍니다. 이 테스트에서는 8개의 코어가 더 나은 성능을 발휘합니다.

이 그래프는 Nginx가 단일 코어에서 얼마나 더 나은(많지는 않지만) 작동하는지 명확하게 보여줍니다. Nginx가 있는 경우 정적 코어만 호스팅한다면 코어 수를 하나로 줄이는 것을 고려해야 합니다.

IIS는 Chrome의 DevTools에 따르면 TTFB가 가장 낮지만 Apache Foundation의 스트레스 테스트와의 심각한 싸움에서 Nginx와 Apache 모두에게 패했습니다.

그래프의 곡률은 모두 철갑으로 재현되어 있습니다.

일종의 결론:

예, Apache는 1코어와 8코어에서는 성능이 떨어지지만 4코어에서는 조금 더 잘 작동합니다.

예, 8개 코어의 Nginx는 1개 및 4개 코어에서 요청을 차례로 더 잘 처리하고 연결이 많을 때 더 나쁘게 작동합니다.

예, IIS는 멀티 스레드 작업 부하에 4코어를 선호하고 단일 스레드 작업 부하에 8코어를 선호합니다. 궁극적으로 IIS는 모든 서버가 동등했지만 부하가 높은 8개 코어를 사용하는 다른 모든 서버보다 약간 더 빨랐습니다.

이는 측정 오류가 아니며 여기서 오류는 +-1ms를 넘지 않습니다. 지연이 발생하며 RPR에 대한 요청은 초당 +- 2-3개를 넘지 않습니다.

8개 코어의 성능이 더 나쁜 결과는 전혀 놀라운 일이 아닙니다. 전체 파이프라인을 완료해야 하는 시간 프레임이 있는 경우 많은 코어와 SMT/하이퍼스레딩으로 인해 성능이 크게 저하됩니다.

출처 : habr.com