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개의 테스트 결과를 묶어서 하나의 그래프로 표현한 것입니다.
2. 각 페이지 단위로 낱개의 응답 현황을 그래프로 확인할 수 있으면 좋겠습니다.
- 아래 그래프는 몇 개의 화면에 대해서 동시 사용자가 증가함에 따라 변화하는 결과를 보여주는 그래프입니다.
위 그래프는 하나하나의 응답 소요시간을 점으로 표현한 내용입니다. 100명의 동시 사용자로 테스트한 경우 다른 화면은 더 적은 동시 사용자가 접근할 때와 큰 차이가 없었지만 I-4,5페이지의 경우 2초 이상 튀는 값이 급증하는 현상을 확인할 수 있었습니다.
아래 내용은 제안 사항은 아니지만, nGrinder를 통해서 발견했던 성능 이슈입니다.
nGrinder를 잘 써온 사용자로, 앞으로 더 활발하게 많이 쓰이는 더 좋은 툴이 되어가면 좋겠습니다.
감사합니다.