개요
- 폴링(Polling): 주기적으로 서버에 요청을 보내 데이터의 변경 사항을 확인하는 방식.
- 웹소켓(WebSocket): 서버와 클라이언트 간의 지속적인 연결을 유지하여 실시간으로 데이터를 송수신하는 방식.
테스트 환경
- JMeter: 성능 테스트 도구로 폴링 및 웹소켓 요청을 시뮬레이션.
- 서버: AWS EC2 인스턴스
- 모니터링 도구:
top -b -d 1 -n 120 > top_output.txt명령어를 사용해 2분간 CPU와 메모리 사용량 모니터링. - 서버 스택: Spring Boot
성능 테스트
폴링(Polling)
폴링 방식에서는 클라이언트가 주기적으로 서버에 요청을 보내 데이터의 변경 여부를 확인합니다. 이번 테스트에서는 다음과 같은 설정을 사용했습니다:
- Number of Threads: 50
클라이언트 10개로 가정하고, 각 클라이언트가 5개의 폴링 요청을 보내는 시나리오입니다. - Ramp-up 시간: 10
모든 스레드를 동시에 시작하지 않고 10초 동안 점진적으로 시작하도록 설정했습니다. - Loop Count: 10
각 스레드가 10번의 요청을 반복 수행합니다. - Constant Timer: 5000
각 요청 사이에 5초의 대기 시간을 설정하여 과도한 요청 폭주를 방지했습니다. - HTTP Request: GET 요청(Polling)
서버에 데이터 변경 사항을 요청하는 GET 요청을 보냈습니다.
웹소켓(WebSocket)
웹소켓 방식에서는 클라이언트와 서버가 지속적인 연결을 유지하여 실시간으로 데이터를 주고받습니다. 이번 테스트에서는 다음과 같은 설정을 사용했습니다:
- Number of Threads: 50
클라이언트 10개로 가정하고, 각 클라이언트가 5개의 웹소켓 연결을 수행하는 시나리오입니다. - Ramp-up 시간: 10
모든 스레드를 10초 동안 점진적으로 시작하도록 설정했습니다. - Loop Count: 1
각 스레드가 한 번만 연결을 수행합니다. - 루프 컨트롤러: 10
각 스레드가 처음 소켓을 연결한 후 10번의 메시지 전송 및 수신을 반복합니다. - Constant Timer: 5000
각 요청 사이에 5초의 대기 시간을 설정하여 안정적인 연결 유지와 데이터 전송을 보장했습니다. - WebSocket Write, Read 반복 수행
각 클라이언트는 서버로 데이터를 보내고, 서버로부터 응답을 수신하는 작업을 반복 수행합니다.
모니터링 스크립트
- top 명령어 사용, 2분간 측정
#!/bin/bash
# top 명령어 출력을 파일로 저장
top -b -d 1 -n 120 > top_output.txt
# CPU 사용률 계산
cpu_usage=$(grep "Cpu(s)" top_output.txt | awk '{usage+=$2} {if($2 > max) max=$2} END {if (NR > 0) print usage/NR, max; else print 0, 0}')
cpu_avg=$(echo $cpu_usage | cut -d' ' -f1)
cpu_max=$(echo $cpu_usage | cut -d' ' -f2)
echo "CPU 사용률 (평균): $cpu_avg%"
echo "CPU 사용률 (최대): $cpu_max%"
# 메모리 사용률 계산
mem_usage=$(grep "MiB Mem" top_output.txt | awk '{used+=$6} {if($6 > max) max=$6} END {if (NR > 0) print used/NR, max; else print 0, 0}')
mem_avg=$(echo $mem_usage | cut -d' ' -f1)
mem_max=$(echo $mem_usage | cut -d' ' -f2)
echo "메모리 사용률 (평균): $mem_avg mB"
echo "메모리 사용률 (최대): $mem_max mB"결과 분석
폴링(Polling)
| 항목 | 시작 전 | 평균 | 최대 |
|---|---|---|---|
| CPU 사용률(%) | 0.3 | 4.2 | 19.0 |
| 항목 | 시작 전 | 종료 |
|---|---|---|
| 사용중 메모리(MB) | 801.2 | 803.4 |
폴링 방식에서는 클라이언트가 1초 간격으로 서버에 요청을 보내는 방식으로 데이터를 수신합니다. 평균 CPU 사용률은 4.2%로 비교적 낮게 나타났으나, 최대 사용률은 19.0%까지 치솟는 모습을 보였습니다. 이는 다수의 클라이언트가 동시에 요청을 보낼 때 서버의 부하가 크게 증가할 수 있음을 시사합니다.
메모리 사용량은 테스트 시작 전 801.2MB에서 종료 시 803.4MB로 약간 증가하였으나, 큰 변화는 없었습니다. 이는 폴링 방식이 주로 네트워크 및 CPU에 부하를 주며, 메모리 사용량에는 큰 영향을 미치지 않음을 나타냅니다.
웹소켓(WebSocket)
| 항목 | 시작 전 | 평균 | 최대 |
|---|---|---|---|
| CPU 사용률(%) | 0.3 | 0.48 | 2.4 |
| 항목 | 시작 전 | 종료 |
|---|---|---|
| 사용중 메모리(MB) | 812.8 | 813.6 |
웹소켓 방식에서는 클라이언트와 서버가 지속적인 연결을 유지하며 실시간으로 데이터를 주고받습니다. 평균 CPU 사용률은 0.48%로 폴링에 비해 매우 낮았으며, 최대 사용률도 2.4%로 폴링에 비해 훨씬 낮았습니다. 이는 웹소켓이 서버에 더 적은 CPU 부하를 주며, 특히 실시간 데이터를 처리할 때 효율적임을 나타냅니다.
메모리 사용량은 테스트 시작 전 812.8MB에서 종료 시 813.6MB로 소폭 증가했습니다. 이는 웹소켓의 연결 유지에 필요한 메모리 소모가 거의 없음을 보여줍니다.
결론
- CPU 사용률: 웹소켓이 폴링에 비해 CPU 사용률이 낮아 효율적임을 확인할 수 있었습니다. 폴링 방식은 주기적인 요청으로 인해 서버의 부하가 가중될 수 있으며, 특히 사용자가 많은 환경에서 서버의 최대 CPU 사용률이 높아질 수 있습니다.
- 메모리 사용량: 두 방식 모두 메모리 사용량의 변화가 미미했으나, 웹소켓이 조금 더 많은 메모리를 사용한 것을 확인할 수 있었습니다. 그러나 이 차이는 실질적으로 거의 영향이 없는 수준입니다.
조제