brunch

You can make anything
by writing

C.S.Lewis

by 임성현 Apr 20. 2016

강연 후기(성능 테스트)

Practical Performance Testing 강연 후기

어제(2016년 4월 19일) D2Startup에서 성능 테스트 강연이 있었습니다. 참석해서 정리한 내용을 공유합니다.


강연자는 윤준호 님이고, nGrinder를 만든 개발자입니다. 

nGrinder는 성능 테스트를 쉽고 빠르고 편리하게 할 수 있도록 만들어진 오픈소스입니다. 

자세한 내용은 nGrinder사이트 를 참조하세요.


저도 4년 전부터 nGrinder를 사용했었고, 제품의 성능진단에 도움을 많이 받았습니다.

관련되어 세미나에서 공유했던 내용을 아래에 첨부합니다.



2013년 3월 공감 세미나 오픈소스/무료 툴을 활용한 부하/성능테스트 사례 소개

  -> 오픈소스와 무료 툴을 활용, 성능 테스트를 수행한 툴 체인에 대해서 소개한 내용입니다.

2015년 4월 KSUG 세미나 내가 써본 nGrinder

  -> 고객사 사이트에서 성능 테스트를 진행한 경험을 단계별로 고민한 내용과 절차를 설명한 내용입니다.



이번 강연은 제품보다는 철학, 그리고 좀 더 일반적인 내용을 설명한 자리였고, 여기에서 얻은 인사이트 몇 개를 공유합니다.

저보다 먼저 공유하신 조대협 님의 어제 성능 엔지니어링 강의에서 들은 몇몇 인사이트 정리 도 참조하시면 좋을 듯합니다.


1. 성능테스트란 ?

  . 스트레스 테스트 : 로드 상황에서  크래시 등의 문제점 확인

  . 로드 테스트 : 로드 상황에서 성능 특성 파악

    로 나눌 수 있다. 하지만, 보통 섞어서 쓰고 있다.


2. 성능테스트 수행 시점은?

  . Analysis phase - 초기 예산 잡을 때. 성능목표 설정(대충 평가)

  . Design phase  - 목표 성능 달성을 위한 설계(예: non-blocking, NoSQL…) 개별 프레임워크 테스트

  . Dev. phase - 중요 성능 키 펙터만 부분적 테스트

  . Testing Time - 실제 성능 확인 및 병목/ 오류 제거


3. 성능테스트 범위

  - 주요 테스트 대상은 ... API

    . 일반적으로는 리소스(로컬 캐시, CDN이므로..), 미디어 제외

    . 서버 랜더링 된 웹 페이지, DB 가끔 테스트

   . 기타 MsgQueue/ cache : 초기 선정시 테스트


4. 서버 용량 산정 : TPS로 확인 어려움. /  클라우드 환경에서는 의미 퇴색

  - 그래서...

    일단 만들고 -> 성능을 측정해본 다음 -> 투입 서버 사양. 개수 결정 -> 이후 비용을 줄이기 위해 최적화

    의 사이클로 진행하는 것을 권고한다.


자세한 내용은 추후 사이트에 올라오는 발표자료를 참조하시면 좋을 것 같습니다.


그렇다면, nGrinder에서 추가적으로 이 기능이 있으면 더 좋겠다.라는 내용을 한번 정리해보았습니다. 참고로 아래 그래프는 nGrinder에서 csv 파일로 내려받아, 다시 엑셀로 표현해보았던 내용입니다.


1. 다수 테스트 결과를 묶어서 그래프로 표현하면 좋겠습니다.

  - 동시 사용자의 수를 바꿔보거나 서버 자원을 변경하고 테스트, 또는 누적 데이터를 변경하면서 동일한 테스트를 진행할 때 다수의 테스트 결과를 묶어서 변화 추이를 볼 수 있으면 좋을 것 같습니다.

  - 특히, 권고 하드웨어 사양이나 최적의 구성환경을 결정할 때 도움이 될 것 같습니다. 동일한 테스트를 버전 릴리스마다 반복할 때에도 도움이 되고요.

  - 아래 그래프는 30개의 테스트 결과를 묶어서 하나의 그래프로 표현한 것입니다. 

동시 사용자가 1, 5, 50, 100, 1000으로 증가할 때 각 시나리오의 응답시간 변화 추이입니다.


2. 각 페이지 단위로 낱개의 응답 현황을 그래프로 확인할 수 있으면 좋겠습니다.

  - 아래 그래프는 몇 개의 화면에 대해서 동시 사용자가 증가함에 따라 변화하는 결과를 보여주는 그래프입니다. 

I-4,5 페이지의 경우 사용자 증가에 따른 민감도가 높습니다.

위 그래프는 하나하나의 응답 소요시간을 점으로 표현한 내용입니다. 100명의 동시 사용자로 테스트한 경우 다른 화면은 더 적은 동시 사용자가 접근할 때와 큰 차이가 없었지만 I-4,5페이지의 경우 2초 이상 튀는 값이 급증하는 현상을 확인할 수 있었습니다.


아래 내용은 제안 사항은 아니지만, nGrinder를 통해서 발견했던 성능 이슈입니다. 

연동 on-off에 따라 응답시간이 큰 차이를 보였던 결과 그래프 입니다.

nGrinder를 잘 써온 사용자로, 앞으로 더 활발하게 많이 쓰이는 더 좋은 툴이 되어가면 좋겠습니다.

감사합니다. 


매거진의 이전글 인재 쟁탈
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari