[7팀 KONO] 웹서버 벤치마킹 테스트 2차 발표자료

[hyogshin]

시나리오

1000 VU, 60초 램프업·3회 반복, 10MB 정적파일

• Ramp up은 HTML/CSS/JS 3개를 받는다는 가정
• 웹서버에서 최대 부하를 넣어보기 위해 10MB 정적파일로 가정 (웹서버에 필요한 최대 정적 파일)
• IQR: 로컬 테스트로 네트워크를 거치기 때문에 이상치(outlier) 처리가 필요

비교군

• WS: Apache, Nginx
• WAS: Tomcat

Apache

A. HTTP 실패량 & 응답 시간 추이

• Ramp-up(00:00–00:00:37) 동안 초당 30–70건의 실패 발생
• 이후(00:00:37–00:01:15)에도 꾸준히 실패 → 1분 정도면 거의 모든 요청이 실패 처리
• 실패율 폭증과 함께 응답 성공(핑크 점) 사실상 0에 수렴
• 초기 소수 요청(00:00–00:00:37)만 정상 응답(수 ms)
• 이후 곧바로 응답 지연 30 000 ms → 240 000 ms → 360 000 ms로 선형 상승
• 이는 JMeter 타임아웃(기본 60 000 ms) 설정을 넘어서면서 "응답 없음(keep-alive 큐 정체)" 상태가 지속된 결과

B. 활성 스레드 상태

• 0초: 390 스레드 시작 → 60초 램프업 끝무렵 약 465 스레드 도달
• 약 75초(00:01:15) 지점에서 다시 390 스레드로 급락 → 스레드 수는 유지되나 요청 처리 불능
• 스레드가 "응답 대기"로 묶여 새로운 요청을 처리 못 함 → 결국 타임아웃만 누적

C. 원인 요약

1. MPM(prefork/worker) 한계
   • 기본 MaxRequestWorkers(또는 ServerLimit) 도달 → 더 이상 워커(프로세스/스레드) 생성 불가
2. TCP 연결 큐(full)
   • ListenBacklog 부족, Keep-Alive 연결이 해제되지 않아 큐가 채워짐
3. 컨텍스트 스위칭 & I/O 오버헤드
   • 대용량 전송 시 프로세스/스레드 문맥 전환 비용 급증 → 처리율·응답시간 동시 악화

CPU·메모리는 여유(최대 CPU 12.7%)였으므로, 리소스 부족이 아닌 스레드/MPM 설정·TCP 큐 설계 한계가 핵심 병목입니다.

Nginx

1. Throughput (req/s)

• Nginx (오렌지)
  • 초반(13:09) 약 5–6 req/s, 최고(13:10) 약 7–8 req/s
• prometheus (파랑, /metrics 엔드포인트)
  • 초반 약 25 req/s, 최고 약 45–50 req/s

→ prometheus 엔드포인트는 페이로드가 작아 CPU-bound 특성을 보여주고, nginx는 대용량 정적 파일 전송으로 network-bound 특성을 보입니다.

2. CPU Usage

• 최대 약 18% 사용
• 멀티코어(8코어) 서버 기준이라, CPU 사이클 여유 큼

→ CPU 병목 아님

3. Network Traffic

• compression 효율적인지 측정
• Nginx가 apache보다 10배 더 많은 Network Traffic 사용
• 네트워크를 타서 Apache는 세미나실, Nginx는 교육장에서 측정

비교 Nginx vs Apache

1. 처리량 (Throughput)

지표	nginx 13:09–13:11	Apache 03:39–03:43
Peak RPS	7–8 req/s	0.1 req/s 미만 (눈에 띄게 낮음)
Peak 네트워크 전송량	≈40 MB/s	≈4–5 MB/s

결론: nginx가 Apache 대비 10배 이상의 높은 요청·대역폭 처리율을 보였습니다.

2. 지연 시간 (Latency)

• Apache p99(latency)
  • 초기 스파이크 시점(03:42) ≈120 ms
  • 이후 소폭 재현 구간(03:43) ≈20 ms
• 특이점:
  • 테스트 중간(03:39–03:40)에는 거의 응답이 없어(throughput 극저),
  • p99 측정 구간이 단절되거나 왜곡되어 신뢰도가 낮음.

nginx의 경우 p99가 2–3 ms대의 안정적 분포를 보이던 것과 비교하면,
Apache는 “처음 몇 요청만 처리 → 곧바로 대량 실패 → 회복 불가” 패턴이었습니다.

3. 실패율 & 스레드 상태

• HTTP 실패율
  • Apache: ramp-up 동안 초당 30–70건, 이후 평균 ≈145건/s까지 증가
  • nginx: 사실상 0건 (전수 성공)
• JMeter 스레드 그룹
  • 시작 직후 390 → 460 스레드까지 램프
  • 약 1분 후(00:01:15) ≈390 스레드로 급락 후 장시간 정체 → 과부하로 응답 대기
  • 테스트 종료 시 감속(ramp-down)

Apache는 워커 스레드/프로세스가 모두 점유되어, 더 이상 요청을 처리하지 못하고 JMeter 쪽 타임아웃·실패만 쌓였습니다.

4. 서버 리소스

리소스	nginx	Apache
CPU 사용률 (최대)	18%	12.7%
Memory 사용률 (OS 파일캐시)	59.7 → 60.5% (+0.8 pt)	약 7–11% 변동
Disk I/O	캐시 히트로 거의 無	–

• 양쪽 다 CPU·메모리 여유가 충분해,
• nginx는 네트워크가, Apache는 “워커 고갈 + TCP 큐 손실”이 진짜 병목이었습니다.

5. 원인 요약

1. Nginx
   • 이벤트 기반 아키텍처 + sendfile 최적화 덕분에 NIC 대역폭까지 채움
2. Apache
   • 기본 MPM(prefork/worker) 설정으로 워커 수(또는 스레드 수) 빠르게 소진
   • 대용량 파일 전송 시 프로세스 간 문맥 전환 오버헤드, TCP 연결 큐(백로그) 손실

6. 예상 웹서버 튜닝

1. Apache 튜닝

<IfModule mpm_event_module>
  StartServers             2
  MinSpareThreads         25
  MaxSpareThreads         75
  ThreadLimit             64
  ThreadsPerChild         25
  MaxRequestWorkers     1500
  ServerLimit            60
  ListenBacklog          1024
</IfModule>

KeepAliveTimeout   2
MaxKeepAliveRequests  100

sysctl -w net.core.somaxconn=1024
sysctl -w net.ipv4.tcp_max_syn_backlog=1024

• nginx 같은 이벤트 기반 프록시 앞단 배치
• CDN/엣지 캐시 완전 활용

2. HTTP/2 시행

• HTTP 1.1 vs HTTP/2 비교 (Nginx vs Apache)

3. 로드밸런싱 비교

• Docker로 Express 웹 서버 두 개를 띄워서 테스트 (load-receiver에서 동작)

향후 계획

1. Apache MPM/Event 모드 전환

위 설정을 적용하여 워커 수 확장 및 TCP 큐 개선을 진행합니다.

2. HTTP/2 도입

Nginx와 Apache에서 HTTP/2 성능 비교 테스트를 수행합니다.

3. 로드밸런싱

Docker 기반 Express 애플리케이션을 대상으로 로드밸런싱 성능 테스트를 진행합니다.