ENV

테스트 시나리오 : Test 인스턴스 별

Target 인스턴스 Static File Lode TEST

Static File Size : 180Byte

목표값 설정

1) Latency : 1500ms 이상은 서비스 이탈자를 높힘

(체감적으로 느리다고 판단되는 시간)

a) Latency : 모든 지표가 500ms 이하  
a-1) MAX 부하시 : 1000ms 이하   ### 2) Throughtput  
DAU = 100,000  
피크 AU = 70,000  
avg.Access - 1User = 20회 (피크 3배)  
rps = 약 210 ~ 300 rps 이상 [100,000 * 20 / 86,400 * 3 * 3]

Controller && Agent Spec

Local PC Spec

  • MacBook Pro 2021
  • CPU : M1 10Core
  • Memory : 16Gb
  • Internet Connect : 290Mbps / Wireless

Target Server Spec

  1. INSTANCE : AWS EC2 t2.micro

1. Vuser 1

2. Vuser 10

3. Vuser 100

4. Vuser 200

5. Vuser 400

6. Vuser 1000

7. Vuser 2000

문제점 발견

일반적 TPS 그래프는 물결 치는 모양이 아닌 어떠한 임계점에 도달하면 특별한 일이 없으면 수평적 그래프를 보이는 모양이 되어짐 하지만 해당 측정에서는 심장박동 같은 파형이 관찰 됨

Target Server Spec 동일 IP

Vuser 400 측정 시 [[#Local PC Spec]] 테스트

그래프의 TPS가 들쭉날쭉하며, 해당 인스턴스의 CPU 사용량을 확인시 0.6% ~ 20% 미만 사용률 확인

정상적인 부하를 주지 못하고 있다고 판단 됨

아래 그래프는 같은 Target Server에 대한 다른 Local PC의 결과

Controller && Agent Spec

Local 2 PC Spec

  • MacBook Air 2021
  • CPU : M1 8Core
  • Memory : 8Gb
  • Internet Connect : 89Mbps / Wire

초반 Creadit 에 의한 CPU Burst 환경 이후 크레딧 소진 후 그래프가 떨어지는 것을 볼 수있지만 그래도 평균 TPS가 1600 이상 차이가 발생 됨 이미지에는 없지만 해당 부하시 Target Server CPU 사용률이 90% 이상 부하가 걸리는 것을 확인

문제점 찾기

Case 1. 네트워크 환경

기존 Home network WIFI 환경에서 Hot Spot 으로 IP 및 네트워크 세팅 변경 후 실행

기존 네트워크 환경과비슷한 모양의 파형이 나타남 => 네트워크 문제가 아닌 PC 세팅 또는 Controller Agent 문제로 보임

유선 환경은 구축이 불가능하여 TEST 진행 불가

Case 2. nGrinder Controller 및 Agent 재설치

  1. JAVA 재설치
  2. Controller && Agent 재설치

아직도 동일 증상…

TEST Instance 에서 CPU 사용률이 저조한 것을 보면 보내는 쪽에서 문제가있는 것은 분명하다.

  1. 파일 Descriptor 수정
    • 기존 2666 > 65535
    • 증상 개선 안됨

Activity Monitor 패킷을 일정하게 보내는 모습이 확인 됨

펄스 / 틱

일반적으로 패킷을 심장박동처럼 규칙적으로 보내는 것은 네트워크의 안정성과 신뢰성을 높이기 위한 목적으로 사용됩니다. 이러한 패킷 전송 방식은 일반적으로 ‘펄스’ 또는 ‘틱’이라고도 불리며, 지속적인 패킷 전송을 통해 네트워크 상태를 모니터링하고 문제를 조기에 발견할 수 있도록 돕는 것이 목적입니다.

심장박동처럼 규칙적인 간격으로 패킷을 전송하면 네트워크의 대역폭을 효과적으로 사용할 수 있으며, 패킷 전송의 지연이나 손실을 신속하게 감지하고 대처할 수 있습니다. 이를 통해 네트워크의 안정성과 신뢰성이 향상되고, 데이터 전송의 효율성이 높아집니다.

또한, 펄스 또는 틱을 사용하여 패킷을 규칙적으로 전송하는 것은 DDoS 공격과 같은 악성 행위를 예방하기 위한 보안적인 목적으로도 사용될 수 있습니다. DDoS 공격은 대량의 패킷을 일정한 간격으로 보내서 네트워크를 마비시키는 공격으로, 이를 방지하기 위해 일반적으로 규칙적인 간격으로 패킷을 전송하는 방식을 사용합니다.

따라서, 패킷을 심장박동처럼 보내는 것은 네트워크의 안정성과 신뢰성을 높이기 위한 목적으로 사용되며, 이를 통해 데이터 전송의 효율성을 높일 수 있습니다.

1. sudo sysctl -w net.inet.tcp.delayed_ack=0

패킷 전송 간격(기본값 3) 에서 딜레이 0으로 변경 => 증상 동일

2. Mac 소켓 버퍼 크기 변경

1) 송신 소켓 버퍼 최대크기 16MB 증가

sudo sysctl -w net.inet.tcp.sendbuf_max=16777216

=> sysctl: unknown oid 'net.inet.tcp.sendbuf_max'

2) sudo sysctl -w net.inet.tcp.recvspace=1667772 => 증상 동일

3. 인터넷 환경 변경

1) 무선 > 유선 환경 변경 ![](https://i.imgur.com/53HjW9l.png)

4. Docker 환경

Case 1

Controller : Docker Agent : Local

Case 2

참고 : nGrinder 테스트 블로그 Controller : Docker Agent : Docker

Controller

docker pull ngrinder/controller

docker run -d -v ~/ngrinder-controller:/opt/ngrinder-controller --name controller -p 80:80 -p 16001:16001 -p 12000-12009:12000-12009 ngrinder/controller

Agent

docker run --add-host host.docker.internal:host-gateway -v ~/ngrinder-agent-2:/opt/ngrinder-agent -d ngrinder/agent 172.30.1.6:80

run Options

✅ –add-host host.docker.internal:host-gateway 옵션 추가시 컨테이너 내부에서 Host에 접근이 가능해짐

--add-host host.docker.internal:host-gateway

✅–sysctl net.core.somaxconn=65000 –ulimit memlock=-1:-1 –ulimit nproc=1024000:1024000 –ulimit nofile=1024000:1024000 (Linux 환경) TCP 사용량 제한 및 파일 오픈관련 리눅스 제한 해제

docker run --sysctl net.core.somaxconn=65000 --ulimit memlock=-1:-1 --ulimit nproc=1024000:1024000 --ulimit nofile=1024000:1024000 --add-host host.docker.internal:host-gateway -v ~/ngrinder-agent-2:/opt/ngrinder-agent -d ngrinder/agent 172.30.1.6:80

‼️ 그래프 패턴 자체는 해결이 된것으로 보인다. !! TPS / Latency 수준은 Local 환경에 비해 50% 정도의 속도 - 속도가 낮아 패턴이 정상적으로 보이는 것 일 수도 있다.

Case 3

Controller : Local Agent : Docker

‼️ 그래프 패턴 자체는 나쁘지 않지만, Process 가 5개 이상이 되면 에이전트 내부에서

  • net.grinder.communication.CommunicationException: Exception whilst sending message
    • 소켓 사용에 대한 에러 매시지가 출력 됨
    • 컨트롤러 에이전트 모두 도커에서 실행했을 때 6개 Process 이상을 사용하였을 때 나오는 Error 가 Agent만 Docker 에서 사용시 Proces 5개 이상에서 에러 발생

문제는 타겟 SERVER에 충분한 부하를 주지 못하는 것 공격 Server에서 이미 CPU 점유율 및 프로세스를 높히지 못하기 때문에 충분한 부하를 줄 수 없을것