인생이 쓰다!인생쓰

공부/개발록

AB(Apache HTTP server benchmarking tool) 동시 접속자 테스트

Johnal 2023. 11. 8. 11:39
반응형

안녕하세요. ㅎㅎ 오늘 업무중에 어떤 문제가 있어서 사용하다 보니

소개 시켜드리고 싶어서 글쓰기 버튼을 강력하게 눌렀습니다. 필요없으실수도 있겠지만 한번 쯤 보시는거 추천합니다.

 

파ㅓ덕퍼닥..

 

 

 

사건의 발단은 그랬습니다. ..(두둥)

이전에 갑자기 서버에 동시접속이 꽤 많이 몰려서 과부하가 걸린적이 있었습니다. 😂

그렇게 과부하가 터진 서버는 접속자가 접속했을때 밀려져 있는 프로세스 때문에 화면이 제대로 로딩되지 않고 새로고침을 연달아 하게 됩니다.....

이렇게 된다면 서버에 밀린 프로세스들은 더 밀리게 되고 최종에는 터지게 됩니다..

그래서 서버를 재시작해주거나,,밀려있는 프로세스들을 죽여줘야되는거죠 .. ㅠㅠ 

 

 

죽은 프로세스하나,,.

 

 

 

그래서 이번에는 그런 동시접속이 예상보다 늘어났을때를 대비한 작업 및 확인입니다.

일단은 서버의 사양을 늘렸습니다. 더 좋은 CPU를 사용해서 처리속도를 올려주었습니다. 

이정도만 해도 이전보다 훨씬 나은 상황을 보여주겠지만 그걸로는 안된다고 생각했습니다. 😣

그래서 사용한 기능이 AB(Apache HTTP server benchmarking tool)  입니다.  아파치 웹서버 성능검사 도구라고 합니다. 

 

현재 아파치가 어떻게 동작하는지 알수 있고 초당 몇개의 요청을 서비스해주는지 알 수 있습니다.

제가 사용한 기능은 어떤 한 페이지에 설정한 동시 접속 요청을 보내서 성능 측정 정보를 가져올수 있습니다. 

예를 들면 네이버라는 검색페이지에 1000을 동시접속 시켜서 이 요청에 응답한 총 시간을 알수 있는거죠.

그러면 과부화 여부나 여러가지 정보들을 쉽게 알수 있습니다.

하지만 복잡한 보안 인증절차나 상세한 데이터가 필요한 사이트에서 테스트하기에는 힘들 것 같네요.

 


 

사용방법은 간단합니다.

일단 아파치 서버에서만 가능합니다.

 

리눅스 창에서 ab를 입력해보면 간단한 사용법과 다양한 옵션들을 보여줍니다.

옵션들중에서 자주 사용하는 옵션만 가져왔습니다.

 

$ ab
Usage: ab [options] [http[s]://]hostname[:port]/path

 

-n 성능을 검사하기위해 보내는 요청수. 기본값으로 요청을 한번만 보내기때문에 일반적인 성능검사 결과를 얻을 수 없다.
-c 동시에 요청하는 요청수. 기본적으로 한번에 한 요청만을 보낸다.
-g 측정한 모든 값을 'gnuplot' 혹은 TSV (Tab separate values, 탭으로 구분한 값) 파일에 기록한다. 라벨은 output 파일의 첫번째 라인을 참고한다.
-t 성능을 검사하는 최대 초단위 시간. 내부적으로 -n 50000을 가정한다. 정해진 시간동안 서버 성능을 검사할때 사용한다. 기본적으로 시간제한 없이 검사한다.
-v 출력 수준을 지정한다.
4 이상이면 헤더에 대한 정보를,
3 이상이면 (404, 202, 등) 응답코드를,
2 이상이면 경고(warning)와 정보(info)를 출력한다.
-A 프록시를 통해 BASIC Authentication 정보를 제공한다.
:로 구분한 사용자명과 암호를 base64 인코딩하여 전송한다.
-X proxy[:port] 프록시 서버를 사용하여 요청한다.


ab -n 1500 -c 1500 -t 10 https://test.com/page  

 

-n 1500: 1500개의 요청을 보냅니다.
-c 1500: 1500개의 동시 접속을 시뮬레이션합니다.
-t 10: 테스트를 10초 간 진행합니다. 

 

간단하죠?? 이렇게 테스트를 진행하려고 보니까.. 

 

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking *****.or.kr (be patient)
socket: Too many open files (24)

 

이러한 에러가 뜨네요. 오류를 확인해보니 시스템의 파일 디스크립터 리소스 한계에 도달했을 때 발생하는 오류이네요.

파일 디스크립터란 무엇일까요? 

File descriptor는 특정한 파일에 접근하기 위한 추상적인 키라고 할수 있습니다.

간단히 말하면 시스템 내에서 파일, 소켓, 파이프 및 다른 입출력 장치와 상호 작용하기 위한 중요한 개념 중 하나이고 

1500개의 웹사이트 즉 파일이 열리기 위한 리소스가 부족하다는 말이죠.

 


 

ulimit 명령어는 리눅스 및 Unix 기반 운영 체제에서 사용자 프로세스에 대한 리소스 제한을 설정하거나 표시하는 명령어입니다. 

이 명령어를 사용하여 사용자가 생성하는 프로세스의 리소스 사용을 제한하거나 모니터링할 수 있습니다.

 

ulimit - a를 입력해보시면 모든 현재 자원 한계를 나열합니다.

예를 들어, ulimit -c 명령은 코어 덤프 크기 제한을 표시하고 설정하는 데 사용됩니다. 

ulimit -n은 파일 디스크립터 수 제한을 표시하고 설정하는 데 사용됩니다.

 

저희는 파일 디스크립터의 수를 늘려줘야 하기 때문에  -n을 이용해 open files를 늘려줍니다.

ulimit -n 2048 을 이용해 늘려줍니다.

그 후에 기존에 에러가 났던 ab를 이용해서 테스트 페이지를 시뮬레이션 해봅시다.

 

 

 

 

현재 사용중인 페이지여서 가려놓은점 죄송합니다.

보시면 아파치 버전부터 시작해서 사이트명 등 자세한 정보들이 출력되는것을 볼수 있습니다.

 

서버 소프트웨어(Server Software) : Apache
서버 호스트 이름(Server Hostname): 웹사이트 주소
서버 포트(Server Port): 443
SSL/TLS 프로토콜(SSL/TLS Protocol): TLSv1/SSLv3, ECDHE-RSA-AES256-GCM-SHA384, 2048, 256
문서 경로(Document Path): /member/license.html
문서 길이(Document Length): 8981 바이트
동시 접속 레벨(Concurrency Level): 1500
테스트에 소요된 시간(Time taken for tests): 10.041 초
완료된 요청(Complete requests): 1915
실패한 요청(Failed requests): 0
쓰기 오류(Write errors): 0
총 전송된 데이터(Total transferred): 18242447 바이트
HTML 전송된 데이터(HTML transferred): 17491727 바이트
초당 요청 수(Requests per second): 191.24 [#/초] (평균)
요청 당 소요 시간(Time per request):  522.895 밀리초 (평균)
요청 당 소요 시간(Time per request):  5.229 밀리초 (모든 동시 요청을 포함한 평균)
전송률(Transfer rate): 1780.96 [킬로바이트/초] 받음

 

여기서 중요한 부분은 Time take for tests(응답시간) , Time per request(요구에 응답한 시간)정도라고 볼수 있습니다. 

확인해보시면 요청당 소요 시간은 평균 522.895 밀리초로  부하에 걸리지 않고 엄청 쾌적한걸 알 수있습니다. 

 

이처럼 아파치에서는 ab를 이용해 쉽게 확인해 볼수 있습니다. 

테스트는 정말 중요하다고 생각합니다. 갑자기 동시에 다수의 이용자가 몰렸을때

터지는 사이트들은 이처럼 대비가 부족했다고 생각합니다. 꼭 성능 테스트 하시길 바랍니다.! 😄😄

그럼 아디오스!!

 

 

 

ps..

오랜만에 쓰는 개발정보글이라 미흡한점이 있는 것같아서 감안해주시면 좋겠습니다.

문제있는 부분이나 틀린 부분이 있다면 댓글 부탁드립니다.!  

감사합니다.

 

 

728x90
반응형