X
STEN 회원이 되시면 테스팅에 관한 많은 정보와 자료를 공유할 수 있도록 저희가 돕겠습니다.
아이디
패스워드
자동로그인 사용
 
아직 회원이 아니십니까?    
아이디/패스워드를 잊으셨습니까?    

     
   
[질문] 부하테스트의 목적과 이유 그리고 성능 프로파일링에 대한
글쓴이 : IT Tester 날짜 : 14-12-11 15:24 조회 : 17743
안녕하세요 QA업무를 하고 있는 어느 회사의 직원인데요.
질문이 좀 많습니다... QA의 고수님들께서 답변 해주시면 정말 감사하겠습니다 ^^

제가 알고있는 지식에 대한 질문도 몇 가지 있습니다.
다른 점 지적 부탁드립니다.


저의 느낌&차이점이라고 생각되는 것은

1. 성능프로파일링은 어느 함수/클래스/DB Query 등의 문제점 중
[어느 곳에서 병목현상이 일어나는지 유추] 하는 활동이 맞나요??

2. 성능 테스트는 부하&스트레스 테스트와 비슷한 느낌,
어떠한 부하를 주는 행동을 하는 테스트를 진행하는 것으로 알고 있습니다.
위 사항이 맞는지...?

3. J-meter 도구가 위 2번에 해당하는 부하 및 스트레스를 주는 도구인가요?

4. J-meter는 Web Application에만 가능한 도구인가요?
4-1. Web만 적용하는 성능테스트 도구라면,
기본 Windows Application을 테스트하기 위한 성능 테스트 도구는 어떤 도구가 있을까요??
상용, 무료 도구 상관없이 추천 부탁드립니다!

5. 부하테스트를 하는 목적은 무엇인가요?
: 어느정도의 부하가 걸렸을 때, 테스트하고자 하는 S/W의 영향을 알아보는 것인가요?
아니면, 한계점이 어느정도인지를 알아보고자 하는 것인가요?

6. Search를 해보았는데, 부하테스트가 S/W(System)의 병목현상 등의 해결점을 도출해줄 수 있다고도 하던데, 성능 프로파일링을 해주는 것도 아닌데 유추&분석이 어떻게 가능한가요??

중&고수님들의 답변 부탁드립니다!

그래요나에요 14-12-11 17:42
초급자의 답변입니다

1. 
어느 함수/클래스 보다는 DB Query에 대한 이슈사항을 확인하는 활동으로 봐야 할 거같습니다.
성능에 대한 범위 정의 없이는 막연한 성능테스트를 수행할 수 있다는 부분의 명확히 하고 진행해야 합니다.

2. 
- 성능 테스트는 목표 or 기준을 정하고 해당 기준에 부합하는 성능을 측정하는 것을 말합니다.
(자세한 정의는 위키 or 네이버에 찾아도 나옵니다.)
- 부하 테스트는 성능 테스트보다는 목표 or 기준이 명확하지 않지만, planning이 되어 있고, product에 대한 reliability를 확인하기 위험이 더 가깝습니다. 그래서 부하는 임계치 확인하는 말이 많이 언급됩니다.

3. 
- 맞다고 할 수 있습니다. 하지만 테스트 대상에 따라 J-Meter가 적용할 수 없을 수도 있습니다.

4. 
- API에 대한 성능 확인도 가능합니다.
- http://www.sten.or.kr/bbs/board.php?bo_table=market&wr_id=943&sca=04 해당 교육 과정이 답을 줄 수 있을 거 같네요.

4-1.
- Watchhttp, MS Stress Tool, WEBLoadUI, Visual studio, Load Runner, SilkPermance, J-Meter 등등 많이 있습니다

5. 
- 결론을 보고자하는 것이 아니라 목적에 맞게 테스트를 진행하고 목적에 부합하는지 찾기 위함입니다.
- goal이 없는 성능 테스트는 대부분 무의미 하였습니다. 추상적인 goal 보다는 명확한 goal이 있어야 원하는 결과를 얻을 수 있습니다.

6.
병목 구간을 확인 할 수 잇으니, 해결점을 도출 할 수 있다는 의미로 보여집니다.
     
IT Tester 14-12-12 09:00
5번에서 명확한 목표란 구체적으로 어떤게 있을까요?? 예를 하나 들어주실 수 있을까요..??
          
그래요나에요 14-12-12 09:51
한가지 경험한 사례로 보자면...
xxx 구축 프로젝트에서 성능 테스트를 한 경우입니다.

이해관계자가 이해 부족으로 인해 이해에 필요한 정보와 기타 준비를 해야 하는 사전 작업이 먼저 필요하고, 설득을 위한 자료도 필요했습니다.
무리한 요구사항을 제한하기 위한 준비도 필요하구요

버스와 지하철같은 각 정차, 도착에 대한 실시간 정보 서비스를 서버에 보내고 서버는 각 정류소 단말마다 해당 도착 예상 및 현재 버스 정보 위치를 보내는데, 이에 대한 성능 테스트를 하는 것이지요.
위 정보를 가지고 성능 테스트를 진행하는데, 실 서버를 가지고 테스트를하는 부분이기 때문에 사전에 해당 정보가 일주일에 얼마나 쌓이고, 일주일중에 무슨 요일이 가장많은 정보를 가지고 오며, 어느 Time line이 가장 붐비는지 확인이 필요했습니다.
정보를 수집하면서 해당 서버에 대한 CPU와 RAM과 같은H/W 사양을 확인합니다.
그 다음 실제 이 서버가 처리할 수 있는 H/W 사양과 Load가 안걸리고, 버틸 수 있는 임계치를 계산합니다.
(참고로 우리가 사용하는 네비게이션은 처음에 음악과 네이게이션을 동시에 할 수 없었습니다. 왜냐하면 CPU가 755Hz가 안되기 때문에 듀얼 처리가 힘들었기 때문이죠...)
(이 처럼 S/W기능은 있지만, H/W에 따라 구현할 수 있고, 없고의 사양이 있습니다.)
(현재는 H/W 성능에 따라 큰 영향을 미치지 않을 만큼 좋아 졌지만...세세하게 보려면.. 무시하지 못하는 부분이기도 합니다.)
이전에 수집한 정보 및 분석을 통해 성능 시나리오는 작성합니다.
작성한 시나리오는 이해관계자 및 협의부서와 충분한 대화를 해야 합니다.
이때 DBA, DB튜너, PM, PL, 이해관계자가 함께 이야기를 해야 합니다.
Meeting Time에서는 이전 정보를 바탕으로 성능 테스트 담당자는 현 상태와 분석 시 서버가 처리할 수 있는 TPS, 처리량에대한 추정치가 있어야 합니다.
추정치의 경우 저는 사전에 적은 사용자로 먼저 확인 해본 다음 그래프를 통하여 만듭니다.
편의상 추정치의 단위는 "개"로 표시하겠습니다.
1개일 경우의 상태, 2개일 경우의 상태, 5개일 경우, 10개일 경우, 20개일 경우 ...
100개, 200개 10000개까지 확인하는 것은 무의미 하기 때문에 몇개의 샘플링을 통해 추후
100, 200, 500, 1000, 5000, 10000개일 경우 그래프의 추정치를 표현합니다.
(물론 이 추정치는 정확한 것이 아니기 때문에 서버의 성능에 대한 이해가 있으면, 어느 정도 버틸 수 있는지 대략적으로 나옵니다.)
정보를 가지고, 이 서버가 어느 정도로 버틸 수 있는지 임계치를 추정로 확인할 수 있습니다.
실제 성능 테스트를 수행하기 전에 저 같은 경우 서버가 버틸 수 있는 임계치를 실제로 먼저 측정합니다.
측정 된 임계치를 바탕으로 시나리오를 업데이트 합니다.
업데이트 후 성능 테스트를 진행하는데, Network 와 Network 간의 구간 별 사항이나, DB에 대한 Query 처리 서버와 단말간의 전송 및 보여주는 시간, 서버와 핸드폰에 보여지는 시간에 대한 다양한 시나리오를 구성합니다.(하지만 이 모든 것을 수행하기에는 시간적인 제약이 많다는 것은 아마도 아실 겁니다.)
그래서 다양한 시나리오 중에 실제 확인하고자 하는 시나리오를 가지고 성능 테스트를 수행합니다.
수행 수 개발 소스에 있는 DB Query에 부하가 많이 걸리는 경우 서버 알고리즘에 따른 이슈, 서버 및 Oracle 설정에 따라 Limit가 걸려 있어 서버가 최적의 성능을 발휘하지 못하는 경우...등등
많은 경우를 성능 테스트를 통해 찾아 냅니다.
이 사례는 매우 드믈게 벌어지는 Case입니다.
현실은 ......
이 중에 하나도 지켜지지 않고, 테스트 하는 경우도 있고, 부분 적으로 있는 경우가 있는 것은 현실에 맞게 조절하여 Goal을 정하면 될 거 같습니다.

- Produce -
= 성능테스트 대상에 대한 사전 정보 수집 및 분석
- 대상 서버의 H/W 확인
- 임계치 및 성능 목표 수립
- 시나리오 작성(현 상황, 목표, 예상 시나리오, 예상 성능 제반에 대한내용)
- 임계치 측정
- 시나리오 업데이트
- 성능 테스트 수행
- 성능 테스트 결과 정리 및 이슈 정리
- 이슈 개선...및 조치

글을 읽다보면 명확한 목표에 대한 감은 어느정도 잡으시면 제가 이해하도록 쓴게 맞을 거 같네요.
명확한 목표를 가지고 문장으로 정의하기가 참 어렵네요 .ㅎㅎㅎ
다른 중 & 고수님이 정의해 주실거라 봄니다. ㅎㅎ
JustineHan 14-12-13 01:12
질문 내용을 보니, (좀 직설적인 표현이라 양해 부탁드립니다.) 성능테스트 기본이론을 아직 접하지 않으신 분이란 걸 느낄 수 있는데, 시간적 여건이 되시면 기본이론서적은 한번 보시면 많은 도움 되실 거 같습니다.
간단히 답변을 드리면......
1번질문은 맞는 얘기인거 같습니다.
2번질문은 질문이 잘못된 거 같습니다. 성능테스트는 총칭하는 용어이고, 성능테스트의 여러가지 종류중에서 목적에 따라 유형이 분류되는데, 부하테스트,스트레스테스트,Spike테스트 등의 유형이 있습니다.
3번질문은 맞다 입니다. Jmeter는 부하 발생을 해주는 오픈소스기반 성능테스트 툴입니다.
4번은 아니다 입니다. Jmeter에서 제공하는 프로토콜이 초창기에는 Web기반 프로토콜만 지원했는데, 점점 발전하여 소켓통신기반이나, 더 나아가 SAP프로포콜까지도 확장되고 있는 상황입니다.
4-1번 질문은 웹서핑하면 성능테스트 도구에 대한 정보가 무수히 쏟아 지므로 답변 생략하겠습니다.
5번. 부하 테스트의 목적도 여러가지가 있습니다.
    - 해당 시스템이 요구되는 성능수준을 만족하는지 측정해보기 위해 부하를 주는 경우
    - 해당 시스템의 임계성능이 얼마나 되는지 알기 위해 부하를 주는 경우
    - 해당 시스템에서 성능저하를 일으키는 병목지점이 없는지 검증하기 위해 부하를 주는 경우
    - 특정 부하상황에서도 어플리케이션이 정상적으로 서비스되는지 확인하기 위해
    - 기타 여러가지 다양한 목적이 있을 수 있음
6번. 부하테스트를 단순히 부하만 발생시키는 것으로 끝나는 것이 아니라, 부하 발생에 따른 각종 성능수치를 측정하여 분석하는 부분까지 포함됩니다. Web/Was/DB서버 각각의 CPU/메모리 사용률, 응답속도, 그리고, 가장 중요한 TPS 수치를 시간대별로 분석을 해보면, 병목지점 유추를 할 수 있습니다.
병목지점에서 특정 함수나 어플리케이션들 중에 성능저하를 일으키는 병목을 발견하기 위해서는 APM툴을 통한 정밀분석을 하기도 하는데, 이러한 분석을 위해서는 반드시 부하테스트를 해야만 하는 것이지요.
IT Tester 14-12-18 16:12
모두 답변 감사합니다. 성능테스트에 대한 이론을 많이 배우게 된 것 같습니다.
아직 많은 부족함을 느끼고, 시간 될 때 성능테스트 이론에 대한 책 한번 읽어보겠습니다.