공감세미나 성능테스트

개발자를 위한 공감세미나 11 회 - 오픈 소스 / 무료 툴을 활용한 성능 / 부하테스트

Content

2013. 3. 16

오픈소스 / 무료 툴을

활용한

부하 / 성능 테스트

사례소개

1. 동기 - 부하 / 성능테스트

2. 성능 / 부하 툴 소개

3. 설치 가이드

4. 활용 가이드

5. 병목 발견 및 조치

6. 여러가지 함정들

7. 활용 팁

소속 KSUG

발표자 임성현

발표자 이경환


발표자

* 임성현- 스펙트라에서 근무중 ( 차세대 제품개발 /Quality Eng.)

- 전 삼성 SDS 품질 툴 개발 및 지원- 자바개발 14 년차- 전자계산조직응용 기술사- IT 멘토링 ( 한이음 /WoC 등 )

- 정보화역기능 명예강사 ( 소년원 )

* 이경환 - 스펙트라에서 근무중 - 자바개발 5 년차 - 차세대 제품개발 - 개발표준 / Continuous Integration 자동화 - 스프링 기반 단위 / 통합 / 성능 테스트 담당


1. 동기

오픈소스 / 무료 성능 툴이 필요한 이유

- 좀 더 빠른 시점에 => 개발 시점에

- 개발자가 직접 => 자신이 작성한 소스를

- 부담 없이 => 비용 부담 없이 , 설치 부담 없이 ( 설치가 정말 쉽다 !)

- 성능을 고려한 실험을 할 수 있도록 => 이렇게 하면 더 빨라질까 ?

아래의 질문을 해결해봅시다 !

- Filter 를 사용하면 얼마나 성능이 떨어질까요 ?

- 커넥션 풀 세팅을 변경하면 얼마나 빨라지나요 ?

- 보안 라이브러리를 교체하면 얼마나 느려지나요 ?

- 데이터가 100 만 건이 넘으면 조회가 느리다는데 어디가 문제일까요 ?



부하 툴 : nGrinder(http://www.nhnopensource.org/ngrinder/)

자세한 설명은 http://prezi.com/sv1xtz75ybaq/ngrinder/http://ngrinder.642.n7.nabble.com/ngrinder-user-kr-f113.html

http://www.nhnopensource.org/ngrinder/



http://prezi.com/sv1xtz75ybaq/ngrinder/

http://prezi.com/sv1xtz75ybaq/ngrinder/

http://ngrinder.642.n7.nabble.com/ngrinder-user-kr-f113.html




nGrinder 구성 - nGrinder con-troller - Agent

이미지 출처 : http://www.cubrid.org/wiki_ngrinder/entry/general-architecture

http://www.cubrid.org/wiki_ngrinder/entry/general-architecture







성능 툴 : AppDy-namics litehttp://www.appdynamics.com/

참고 사이트http://litedocs.appdynamics.com/display/ADLite/Get+Started+With+AppDynamics+Lite+for+Java

http://www.appdynamics.com/



http://litedocs.appdynamics.com/display/ADLite/Get+Started+With+AppDynamics+Lite+for+Java







AppDynam-ics 지원 사양




성능 툴 : New Relichttp://newrelic.com/

참고 사이트https://newrelic.com/docs/help

http://newrelic.com/



https://newrelic.com/docs/help






New Relic 지원사양



성능 툴 : VisualVMhttp://visualvm.java.net

참고 사이트http://visualvm.java.net/ko_KR/gettingstarted.html

http://visualvm.java.net/

http://visualvm.java.net/ko_KR/gettingstarted.html





성능 툴 : Eclipse Memory Analyzerhttp://www.eclipse.org/mat/downloads.php

http://www.eclipse.org/mat/downloads.php




3. 설치 가이드 - overview

시나리오

AgentAgentScript

DB 서버Oracle

모니터링

부하 테스트 (Stress test) 성능 모니터링

System Under Test

Egov…..WAS 서버

AgentAgentAgent


3. 설치 가이드

1) nGrinder :

http://sourceforge.net/projects/ngrinder/files/

참조 : http://junoyoon.tistory.com/entry/nGrinder-%

EC%84%A4%EC%B9%98%EB%B0%A9%EB%B2%95

2) AppDynamics : http://

www.appdynamics.com/curious-about-pricing

3) New Relic : 회원가입 후 License Key, Agent 다운로드



http://junoyoon.tistory.com/entry/nGrinder-%EC%84%A4%EC%B9%98%EB%B0%A9%EB%B2%95

http://junoyoon.tistory.com/entry/nGrinder-%EC%84%A4%EC%B9%98%EB%B0%A9%EB%B2%95

http://www.appdynamics.com/curious-about-pricing

http://www.appdynamics.com/curious-about-pricing


3. 설치 가이드 - nGrinder

실행 후


3. 설치 가이드 - AppDynamics


3. 설치 가이드 - New Relic


3. 설치 가이드 - 테스트 대상 환경 구성

1. Windows 7 / Tomcat 6.0.36 / Oracle 11g XE / Java 1.6.0_352. 테스트 대상 web application 구성

전자정부프레임워크 의사소통관리 2.0http://www.egovframe.org/cop/bbs/selectBoardArticle.do?nttId=444&bbsId=BBSMSTR_000000000121&menu=2&submenu=3 (oe1.war 로 변환 후 구동 )

http://www.egovframe.org/cop/bbs/selectBoardArticle.do?nttId=444&bbsId=BBSMSTR_000000000121&menu=2&submenu=3




3. 설치 가이드 - 테스트 대상 환경 구성

http://sleeplessinslc.blogspot.kr/2012/02/spring-security-stateless-cookie-based.html





3. 설치 가이드 - Port 정리

Port 정리< 수정 필요 >1. 테스트 대상 서버 (SUT) /conf/web.xml :

shutdown port=8885service port=8888 ajp port=8889

2. nGrinder controller /conf/web.xml : shutdown port=18005service port=18080ajp port=18009

< 수정 안함 >3. nGrinder Agent user/.nGrinder_agent/agent.conf controller port=16001

4. AppDynamics viewer adlite-view port=8990

5. The Grinder TCPProxy port=8001

6. SpringSecurity Example jetty port=8080


3. 설치 가이드 - 모니터링 / TCPProxy 준비

1. 모니터링 _DEV_/SUT/apache-tomcat-6.0.36/bin/catalina.bat 수정 javaagent 옵션 활용

2. 레코딩 _DEV_/tcpproxy.bat 파일 생성


3. 설치 가이드 - egov 셈플 수정

동시접속자 제한을 제거- context-security.xml 파일 128 라인 주석화


4. 활용 가이드

< 다음사항을 알아보겠습니다 . >

1) nGrinder Basic - JYTHON!!!

2) 저장된 스크립트 구동

3) Record & Play (jython 의 장벽을 넘을 수 있는 막강 도구 )

4) Session 처리

5) POST 방식

6) JSON 처리

7) 시퀀스

8) Doc 생성


4. 활용 가이드

1) nGrinder Basic - JYTHON!!!(java 만 알면 까막눈 )


4. 활용 가이드

2) 저장된 스크립트 구동3) Record & Play(jython 의 장벽을 넘을 수 있는 막강 도구 ) - tcpproxy.bat 수행


4. 활용 가이드

- 브라우저 proxy 설정


4. 활용 가이드

4) Session 처리 – nGrinder 에서 기본 제공5) POST 방식

6) JSON 처리 – 스크립트 만들 때 라이브러리 / 리소스 폴더 생성 후 json 라이브러리 업로드


4. 활용 가이드

7) 시퀀스 – 동일한 USER ID 를 막는다면 ? -> python 의 글로벌 변수 활용8) Doc 생성 – groc 활용 (http://blog.outsider.ne.kr/907)

http://blog.outsider.ne.kr/907

http://blog.outsider.ne.kr/907


5. 병목발견 및 조치

< 다음 사항을 알아보겠습니다 >

1. 성능 측정과 함께 모니터링 해야 할 것

2. 성능 측정 후에 모니터링 해야 할 것

3. WAS 가 죽거나 멈췄을 때 확인해야 할 것



* 성능 측정과 함께 모니터링 해야 할 것1) WAS 성능 모니터링





* 성능 측정과 함께 모니터링 해야 할 것2) WAS 의 thread 모니터링 . ( 부하가 잘 들어가고 있는지 알 수 있습니다 .)



* 성능 측정과 함께 모니터링 해야 할 것3) SUT( 대상시스템 ) 과 연계시스템 (DB, WebService 등 ) 의 resource 확인 CPU , MEMORY, DISK, NETWORK



* 성능 측정과 함께 모니터링 해야 할 것4) visualvm 의 sampling 플러그인을 사용하여 java method 별 병목 파악 .



* 성능 측정과 함께 모니터링 해야 할 것 snapshot 을 보면 세부적인 callstack 과 시간을 볼 수 있습니다 .



2. 성능 측정 후에 모니터링 해야 할 것

1) Test 데이터 확인 .

등록건수 / 조회건수 등에 대해서 정확하게 변경되었는지 확인 .

동시접속 제한 등으로 미실행건이 있는지 확인

=> Logic 이 수행되지 않았기 때문에 TPS 가 과다 산정

2) Error 확인

에러 로그를 확인 , 에러를 전부 제거한 뒤에 다시 부하테스트 시도



3. WAS 가 죽거나 멈췄을 때 확인해야 할 것1) SYSTEM log 를 확인 (WAS 가 어떤이유로 죽었는지 .)

2) visualvm 으로 memory, gc 를 확인 .

(GC 가 짧은간격 호출되고 호출 이후에도 메모리가

내려가지 않고 높다면 메모리가 부족한것 .)

3) memory leak 은 visualvm 으로

heap dump 를 받아서 확인한다 .

-Xmx 가 너무 적게 잡으면 발생

-Xmx 가 너무 크면 시스템이 리소스를 독점하고 ,

full GC 에 많은 시간이 걸려 오히려 역효과



3. WAS 가 죽거나 멈췄을 때 확인해야 할 것 Memory Analyzer(MAT)


6. 여러가지 함정들

1. [nGrinder]windows xp 에서 agent 를 설치하는 사용자의 함정 Default : C:\Docment and Settings\user\.ngrinder_agent 경로에 " " 가 들어가면 실행시 에러 발생 . 해결 방안 : AGENT 사용시 - NGRINDER_AGENT_HOME=c:\ngrinder\agent_home CONTROLLER 사용시 - NGRINDER_HOME=c:\ngrinder\controller_home TOMCAT 사용시 - CATALINA_HOME=c:\ngrinder\controller

2. [AppDynamics] 구동되면서 OOM permgen space exception 발생할 수 있음 . 해결 방안 : -XX:MaxPermSize=128m permgen 영역을 조금 더 여유 있게 설정

3. [SUT]dbpool 이 함정 . DB pool 은 느리지 않습니다 . DB 에서 처리하는 시간이 늘어나면서 pool 이 부족해 질 수 있습니다 . DB pool 관련 method 의 처리시간이 길어지고 pool 에 반환하지 못하면서 대기시간이 길어집니다 . DB pool 설정을 무작정 늘리는 것은 좋지 않다 . 아래의 설정은 DB pool 역할을 못한다 .

<property name="initialSize" value="0"/> <property name="maxActive" value="8"/> <property name="maxIdle" value="0"/> DB Pool 을 사용하지 않는 것과 같다 .


7. 활용 팁

1. [SUT] 실행 에러를 없애고 테스트 수행할 것

- error 있는 소스가 tps 나 응답시간이 외곡될 수 있다 . 에러처리가 우선 !!(TPS/ 응답시간만 보고 성능이 개선되었다고 착각 )

- grinder.statistics.forLastTest.setSuccess(False) 처리시 많은 에러가 나면 테스트가 중간 종료됨

2. [nGrinder] 시나리오는 심플하게

- 스크립트 만들기도 어렵고 , 에러 수정하기도 어렵다 .

- 시나리오가 복잡하면 평균 TPS 를 통해 어디가 병목인지 확인이 어렵다 .

3. [nGrinder] 실행 우선 , 서서히 다듬기 .

- 먼저 잘 실행되는 스크립트를 만들고 모니터링 하면서 개선한다 .

4. [SUT] 시스템의 이해가 필요 .

- 로그인 중복 방지 경우 (user+timestamp 로 로그를 남기는 경우 동시에 로그인하면 키중복 에러 )

- 동일 사용자의 경우 조회수가 변동되지 않는 경우

- spring security 의 session, 동시사용자 제한등을 풀어야 제대로 부하를 주는 테스트를 할 수 있다 .

5. [ 전략 ] 테스트 구동 서버 , agent, 모니터링 서버 확보

- 동일 서버에서 구동시 과도 부하 발생


7. 활용 팁

6. [ 전략 ]DB 를 사용하는 어플리케이션이라면 DB 튜닝과 함께 병행 준비

- 성능저하 포인트는 결국 DB 에서 만나게 된다 .

7. [nGrinder]script 검증과 부하테스트 환경의 차이 감안 (Agent 의 127.0.0.1 상황 )

- SUT 에 대한 부하는 nGrinder Agent 에서 주기 때문에 원격서버에 설치된 경우 방화벽 설정에 주의

- script 의 검증은 nGrinder controller 에서 수행하고 실제 부하 테스트 시에는 nGrinder Agent 에서 접근함 .

8. [nGrinder]Script Gallery 를 꼭 구경하자 .

- nGrinder 의 모체인 The Grinder 가 어떤 기능을 제공하는지 파악 가능 http://grinder.sourceforge.net/g3/script-gallery.html#form.py

9. [ 전략 ] 적정 시간 이상 테스트를 수행한 뒤 측정

- 30 분이상 부하를 준뒤 성능을 수치를 측정하는것이 좋습니다 .

- 따라서 , 시간이 많이 소요되는 테스트 !!( 야근주의 )

10. [SUT] 동일한 환경에 기술요소를 다르게 하여 성능개선 포인트 확보 가능

- tomcat 의 connector 를 APR 로 바꿨을때

- apache 와 nginex 의 비교 .

- 커넥션 풀을 Apache DBCP 를 boneCP 로 바꿨을때 .

http://grinder.sourceforge.net/g3/script-gallery.html#form.py




7. 활용 팁

11. [ 전략 ] 오픈소스 개발자에게 감사를 표시하자

- http://ngrinder.642.n7.nabble.com/ngrinder-user-kr-f113.html




감사합니다 .

임성현 : [email protected]이경환 : [email protected]

mailto:[email protected]

mailto:[email protected]

Technology

공감세미나 성능테스트