동영상 서버 스트레스 테스트

| 2019년 2월 12일 | 0 Comments

 

Nginx서버에서 MP4동영상 , RTMP VOD STREAMING 플레이

스트레스 테스트를 진행했습니다.

 

목적 : Nginx 에서 MP4RTMP VOD 스트리밍 동영상의 플레이량 체크

 

테스트환경:

명칭

아이피

하드웨어

목적

Nginx 서버

192.168.0.66

2 Core 4GB

Nginx web/RTMP 서버

Client 서버

192.168.0.68

1 Core 1GB

스트레스 테스트 툴 설치

 

테스트 툴 : SRS_bench

    – 장점:

            1) 동시다발적 클라이언트 연결 시뮬레이션 가능 : 2G 메모리로 300,000의 연결 가능

            2) HLS의 분석과 로드테스트 기능 : HLSVODLIVE 플레이테스트 가능

            3) HTTP 로드테스트기능 : 한가지 파일을 다운로드 함으로써 부하테스트 가능

            4) RTMP VOD STREAMING 테스트 기능 : 한개 프로세스에 5000개 시뮬레이션 가능

            5) RTMP LIVE Publish 테스트 기능 : 한개 프로세스에 500개 시뮬레이션 가능

    – 주의점:

            1) HTTP/HLS : 서버의 Content-Length, Chunked 방식을 지원하지 않습니다.

            2) 모든 프로그램은 Linux에서 진행합니다.

 

툴 설치 : 

     # git clone https://github.com/simple-rtmp-server/srs-bench.git
     # cd srs-bench && ./configure && make && 
     # ll srs_bench/objs
     sb_hls_load                //HLS 로드 테스트 명령어
     sb_http_load               //HTTP로드 테스트 명령어
     sb_rtmp_load               //RTMP플레이 로드 테스트 명령어
     sb_rtmp_load_fast 
     sb_rtmp_publish            //RTMP라이브 로드 테스트 명령어

툴 사용법 : 

     - RTMP VOD STREAMING 플레이 시뮬레이션  
     # ./sb_rtmp_load -c 1000 -r rtmp://192.168.0.104/vod/video.mp4

     - RTMP PUBLISH STREAMING 플레이 시뮬레이션
     # ./objs/sb_rtmp_publish -i video.mp4 -c 1 -r rtmp://192.168.0.104/vod/video

     - HLS LIVE 플레이 시뮬레이션
     # ./objs/sb_hls_load -c 1 -r http://192.168.0.104/vod/video.m3u8 

     - HLS VOD 플레이 시뮬레이션
     # ./objs/sb_hls_load -c  1 -o  -r http://192.168.0.104/vod/video.m3u8 

     옵션  
     -c : 클라이언트수 설정(default:1, 10000개의 클라이언트면 -c 10000)
     -r : URL (-r rtmp://192.168.0.104/vod/video.mp4)

 

 

테스트 과정

1. MP4 플레이 스트레스 테스트

1) Client 서버에서 동시다발적 100개 클라이언트 시뮬레이션 시도

# ./sb_http_load -c 100 -r http://192.168.0.66/KDA.mp4 
...
[2019-02-11 13:18:04.975][96][trace] start random sleep 3680ms
[2019-02-11 13:18:04.975][97][trace] start random sleep 5330ms
[2019-02-11 13:18:04.975][98][trace] start random sleep 4738ms 
[2019-02-11 13:18:04.975][99][trace] start random sleep 4513ms
[2019-02-11 13:18:04.975][100][trace] start random sleep 4816ms 
[2019-02-11 13:18:10.469][86][trace] start to process HTTP task #86, schema=http, 
host=192.168.0.150, port=80, path=/KDA.mp4, 
[2019-02-11 13:18:34.971] [report] [24940] threads:100 alive:100 duration:30 
tduration:0 nread:812.13 nwrite:0.00 tasks:103 etasks:0 stasks:0 estasks:0 

– Nginx 웹서버에서 CPU사용량, load 정황, 메모리 사용량 체크(htop 사용)

– Nginx 웹서버에서 80포트에 연결성공한 클라이언트 확인

 

2) Client 서버에서 동시다발적 2000개 클라이언트 시뮬레이션 시도

# ./sb_http_load -c 2000 -r http://192.168.0.66/KDA.mp4
... 
[2019-02-11 13:34:58.823] [report] [24964] threads:2000 alive:1978 duration:247 
tduration:0 nread:9.33 nwrite:0.01 tasks:2966 etasks:988 stasks:0 estasks:0 

– Nginx 웹서버에서 CPU사용량, load 정황, 메모리 사용량 체크(htop 사용)

– Nginx 웹서버에서 80포트에 연결성공한 클라이언트 확인

 

2. RTMP VOD STREAMING 스트레스 테스트

1) Client 서버에서 동시다발적 1000개 클라이언트 시뮬레이션 시도

# ./sb_rtmp_load -c 1000 -r rtmp://192.168.0.150/apple/KDA.mp4 
[2019-02-11 13:53:20.572] [report] [25004] threads:1000 alive:1000 duration:90
 tduration:0 nread:694.47 nwrite:0.31 tasks:1000 etasks:0 stasks:0 estasks:0 

– Nginx RTMP서버에서 CPU사용량, load 정황, 메모리 사용량 체크(htop 사용)

– Nginx RTMP서버에서 1935포트에 연결성공한 클라이언트 확인

 

2) Client 서버에서 동시다발적 2000개 클라이언트 시뮬레이션 시도

# ./sb_rtmp_load -c 2000 -r rtmp://192.168.0.150/apple/KDA.mp4  
[2019-02-11 13:49:11.548] [report] [24996] threads:2000 alive:2000 duration:60 
tduration:0 nread:367.62 nwrite:1.42 tasks:3082 etasks:1082 stasks:0 estasks:0 

– Nginx RTMP서버에서 CPU사용량, load 정황, 메모리 사용량 체크(htop 사용)

– Nginx RTMP서버에서 1935포트에 연결성공한 클라이언트 확인

– Nginx RTMP서버에서 로그파일 확인

[root@wdseo-5016 ~]# tail -f /usr/local/nginx/logs/r_access.log 
192.168.0.68[11/Feb/2019:13:56:31 +0900]PLAYappleKDA.mp4-39326548503WIN 15,0,0,239
192.168.0.68[11/Feb/2019:13:56:31 +0900]PLAYappleKDA.mp4-39327139617WIN 15,0,0,239 
... 

 

결론: Nginx RTMP서버에서는 클라이언트의 수가 많아질수록 MP4테스트할시 메모리의 사용량보다 현저히 높아지는것을 볼수 있습니다. TCP의 연결상태도 2000개이상이 넘어가면 타임웨이팅 현상이 더욱 심해집니다. 서버의 하드웨어부족함도 있지만 클라이언트의 하드상황도 좋지 않은 원인으로 2000개 이상의 request를 보내면 에러의 현상이 많아집니다. 자세한 서버설정은 아래에 있습니다.

 

추가설명: 1000, 2000,10000등의 많은 연결수를 시도할수록 Nginx 설정 및 서버 tcp connection에 관한 설정들도 수정하여야 합니다. 수정하지 않았을시 Default로 설정되였던 수를 초과하여 에러가 발생하거나 테스트 결과가 정확하지 않는 경우가 있습니다.

 

서버설정

1. Nginx 설정

#vim /usr/local/nginx/conf/nginx.conf
worker_processes auto; 
worker_rlimit_nofile 10240;
events { 
worker_connections 10240;
}
옵션
worker_processes : CPU개수
worker_rlimit_nofile : 프로세스가 동시에 사용할 수 있는 파일의 수
worker_connections : Connection 수를 서버하드 정화에 따라 설정

2. ulimit

많은 개수의 소켓을 사용하는 서버 프로그램은 구동하기 전, ulimit 명령어로 프로세스 당 최대 파일 개수를 증가시켜주어야 할 것입니다.

# ulimit -n 20000 

3. 커널 파라미터

1) maximum file count

리눅스에서 전체 시스템이 가질 수 있는 최대 파일 개수 제한은 ‘fs.file-max’ 커널 파라미터에서 설정 됩니다. (/etc/sysctl.conf에서 추가)

#sysctl fs.file-max
fs.file-max = 775052

(이 값을 넘어가면 open() 시스템 콜에서 ‘Too many open files’와 같은 에러가 발생 될 것 입니다.)

2) backlogs

수신 연결 요청의 높은 비율이 연결 실패가 될 때 다음 매개변수를 변경한다.

#vim /etc/sysctl.conf
net.core.somaxconn = 3000
net.ipv4.tcp_max_syn_backlog = 3000
net.core.netdev_max_backlog = 3000
net.ipv4.tcp_synack_retries = 3
net.netfilter.nf_conntrack_max = 65536
# sysctl -p //추가후 적용

추가설명 : 서버하드정황에 따라 위에 수치를 수정하여야 한다.

 

기타 스트레스 테스트툴 사용

• ab

• wrk

• JMeter

• NeoLoad

많은 스트레스 툴이 있지만 주요 테스트툴로 사용하지않은 원인: 이번 테스트 목적은 동영상 플레이량에 따라 서버에 주는 부하를 측정하고싶었고 위의 ab, wrk툴은 mp4, RTMP플레이기능이 없고 JMeter java기반의 툴로 따로 플러그인을 추가하여 사용하는데있어 불편함을 느꼈습니다. 플러그인 찾기도 설치하기도 어려웠습니다. 이외 NeoLoad는 라이선스가 필요하면서 무료로 테스트하기엔 한도가 느껴졌습니다.

 

1. ab (Apache HTTP server benchmarking tool)

ab는 아파치 하이퍼텍스트 전송 프로토콜 (HTTP) 서버의 성능을 검사하는(benchmarking) 도구이다. 현재 아파치가 어떻게 동작하는지 알려준다. 특히 아파치가 현재 초당 몇개의 요청을 서비스하는지 알려준다.

툴 설치 :

# yum install httpd-tools 

툴 사용법 :

# ab -c 20 -n 500 http://192.168.0.150/index.html
//동시에 20명이 요청하는데 합산해서 요청 수가 500 이라는 의미 ( 20 x 25 = 500 )  
Benchmarking 192.168.0.150 (be patient)
...(생략)
Completed 500 requests
Finished 500 requests
...(생략)
Time taken for tests: 0.098 seconds
Complete requests: 500
Failed requests: 0
...(생략)
Requests per second: 5097.10 [#/sec] (mean)
Time per request: 3.924 [ms] (mean)
Time per request: 0.196 [ms] (mean, across all concurrent requests)
Transfer rate: 1652.58 [Kbytes/sec] received
...(생략)
옵션
-c 옵션 : 동시 요청수 (아래의 -n 횟수 보다 이하의 수여야 한다.)
-n 옵션 : 요청 횟수 

 

2. wrk

wrk는 HTTP/HTTPS 벤치마킹 도구입니다.상당한 부하 생성을 할 수 있고 LuaJIT스크립트를 통해 HTTP/HTTPS Request 요청 Header과 전송 데이터 설정을 할 수 있습니다. Web서버의 Response 응답 후처리 하고 리포트에 필요한 데이터를 수집할 수도 있습니다.

장점:

            1) 터미널에서 가볍게 사용하기 좋습니다.

            2) lua 스크립트를 쓸수 있습니다.

주의점:

            1)보낸 요청 개수가 정확하지 않습니다.

            2)자세한 리포트나 그래프를 만들어주는 기능이 없습니다.

툴 설치 :

# git clone https://github.com/wg/wrk 
# ./configure && make &&    

툴 사용법:

# ./wrk -t4 -c1000 -d60s --latency http://192.168.0.150/index.html  
Running 1m test @ http://192.168.0.150/index.html
4 threads and 1000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 31.09ms 29.59ms 727.11ms 97.26%
Req/Sec 6.98k 2.84k 18.57k 67.75%
Latency Distribution
50% 27.35ms
75% 32.84ms
90% 38.94ms
99% 202.74ms
1015582 requests in 1.00m, 326.35MB read
Requests/sec: 16906.64
Transfer/sec: 5.43MB
옵션
-t thread 개수
-c Connection 개수
-d 테스트시간
--latency 반응시간 결과측정 추가

 

3. JMeter

위키에서 Apache Jmeter (https://en.wikipedia.org/wiki/Apache_JMeter)대한 설명 다음과 같습니다.

Apache JMeter is an Apache project that can be used as a load testing tool for analyzing and measuring the performance of a variety of services, with a focus on web applications. JMeter can be used as a unit-test tool for JDBC database connections,FTP,LDAP,Webservices,JMS,HTTP,generic TCP connections and OS native processes. One can also configure JMeter as a monitor,although this is typically considered ad hoc rather than advanced monitoring. It can be used for some functional testing as well.

툴 설치 : 우분투에서 패키지 관리자로 설치 가능합니다.

툴 사용법 :

1) 먼저 시나리오를 만들어서 그 안에 스레드 그룹을 만들고 유저수(스레드)와 몇 번 반복할지를 입력합니다.

2) 그 다음 원하는 add 버튼을 눌러서 프로토콜의 request를 추가하고 server ip와 포트를 입력하고 인자 값까지 추가 할수 있습니다.

3) 리포트는 graph, summary, table 등 다양하게 있습니다. 보고 싶은 리포트가 있다면 add 버튼에서 listener를 추가할 수 있습니다.

추가설명:  위의 테스트 툴이 웹서버에만 한정해서 테스트가 가능했다면 JMeter은 서버 전체의 다양한 테스트가 가능했습니다. 부하테스트만 할 생각인데 불필요할 정도로 기능이 많고 플러그인도 많고 부하 테스트 외 다른 테스트 목적으로도 쓸모 있어 보였습니다.

 

4. NeoLoad

웹 및 모바일 응용 프로그램의 성능을 측정하는 로드 및 스트레스 테스트 도구입니다. NeloLoad는 개발자가 응용 프로그램을 제작하기전에 성능을 최적화 할수 있도록 실용적인 솔루션을 제공합니다.

장점:

            1) GUI 기반의 UI

            2) 빠르고 신뢰성있는 테스트

            3) 빠르고 신뢰성있는 테스트

            4) 안전한 새로운 기술 구현

주의점:

            1) 라이선스가 필요하다.

툴 사용법 : 사용방법이 복잡하므로 구글해보시길 바랍니다.

 

 

 

 

 

 

Category: 동영상/CDN

About the Author ()