데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...Amazon Web Services Korea
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study
이 세션에서는 데브시스터즈의 Case Study를 통하여 Data Lake를 만들고 사용하는데 있어 요구 되는 사항들에 대해 공유합니다. 여러 목적에 맞는 데이터를 전달하기 위해 AWS 를 활용하여 Data Lake 를 구축하게된 계기와 실제 구축 작업을 하면서 경험하게 된 것들에 대해 말씀드리고자 합니다. 기존 인프라 구조 대비 효율성 및 비용적 측면을 소개해드리고, 빅데이터를 이용한 부서별 데이터 세분화를 진행할 때 어떠한 Architecture가 사용되었는지 소개드리고자 합니다.
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...Amazon Web Services Korea
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study
이 세션에서는 데브시스터즈의 Case Study를 통하여 Data Lake를 만들고 사용하는데 있어 요구 되는 사항들에 대해 공유합니다. 여러 목적에 맞는 데이터를 전달하기 위해 AWS 를 활용하여 Data Lake 를 구축하게된 계기와 실제 구축 작업을 하면서 경험하게 된 것들에 대해 말씀드리고자 합니다. 기존 인프라 구조 대비 효율성 및 비용적 측면을 소개해드리고, 빅데이터를 이용한 부서별 데이터 세분화를 진행할 때 어떠한 Architecture가 사용되었는지 소개드리고자 합니다.
급증하는 온라인 사용자 증가, 부하테스트가 필요하지 않으신가요?
요즘 인터넷 뉴스에는 홈페이지 접속자 폭증으로 인한 서버 다운, xx은행 모바일 앱 접속 에러, 인터넷 뱅킹 장애 등 온라인 시장과 모바일 시장이 급격하게 성장함에 따라 이에 따른 장애 소식이 끊이지 않고 전해지고 있습니다.
그렇다면, 우리는 이런 장애들을 어떻게 대비할 수 있을까요?
웹∙앱 부하테스트 (성능 진단) 및 컨설팅 안은 웹∙앱 부하테스트(성능 진단 테스트) 진행 과정과 이를 기반으로 어떻게 컨설팅을 진행하고 있는지 소개하고, 나아가 관련 장애들을 대비할 수 있는 방법에 대해 설명합니다.
(공유드리는 파일은 slideshare에 업로드되었던 웹∙앱 부하테스트 성능 진단 및 컨설팅 안을 업데이트한 최신 본입니다.)
웹∙앱 부하테스트 (성능 진단) 및 컨설팅 자료는 아래와 같이 구성되어있습니다.
• 웹∙앱 성능을 진단하고 문제에 대한 원인 분석 및 개선방향을 제시합니다.
• 컨설팅 안에는 여러 실 성능 진단을 예시로 들고 이에 대한 원인 분석 및 개선방향을 도
출한 내용이 포함되어 있습니다.
1. 앱 성능 진단
• 앱 진단 절차
• 앱 진단 상세 내용
2. 웹 서버 성능 진단
• 웹 진단 절차
• 웹 진단 방향
3. 부하 테스트
• 현 테스트 시나리오 분석
• 테스트 시나리오 보완 방법
• 부하 테스트 진행 방안
• 부하 테스트 전략
• 클라우드 기반 테스트 방안
모바일 성능 모니터링, 웹 서버 성능 진단 및 부하테스트 컨설팅에 관심이 있으신 분은 아래 연락처로 연락해주시면, 전문 컨설턴트가 안내해드리겠습니다.
hhjung@onycom.com l 02-6395-7722
[오픈소스컨설팅]Day #1 MySQL 엔진소개, 튜닝, 백업 및 복구, 업그레이드방법Ji-Woong Choi
MySQL 소개
간략한 소개
version history
MySQL 사용처
제품 군 변화
시장 변화
MySQL 구성
MySQL 클라이언트 / 서버 개념
클라이언트 프로그램
MySQL 설치
MySQL 버전
MySQL 설치
MySQL 환경 설정
환경설정, 변수 설정
MySQL 스토리지 엔진 소개
MySQL tuning 소개 및 방법
데이터 백업/복구 방법
백업
복구
MySQL Upgrade
An introduction to the advantages of the features of JMeter 4.0. In addition, I will talk a little bit about the way that a real project applies it for continuous integration on TeamCity to get the test result in every day
Load Testing Best Practices: Application complexity is increasing, yet the stringent requirements for web performance is increasing exponentially. Learn more about the three major types of load testing, determine which you need and how to conduct them.
2022년 11월 30일 코엑스에서 개최한 베스트콘2022(Better Software Testing Conference 2022)에서 발표한 강연 자료입니다.
대규모 장애를 막기 위해 소프트웨어/품질 엔지니어가 알아야 할 내결함성의 개념과 설계 기법을 공유드립니다.
생생한 강연 영상으로 확인해 보세요!
https://youtu.be/OLsv7oG0VPo
JMeter is an Apache Jakarta project that can be used as a load testing tool for analyzing and measuring the performance of a variety of services, with a focus on web applications.
www.silenceit.ca
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
급증하는 온라인 사용자 증가, 부하테스트가 필요하지 않으신가요?
요즘 인터넷 뉴스에는 홈페이지 접속자 폭증으로 인한 서버 다운, xx은행 모바일 앱 접속 에러, 인터넷 뱅킹 장애 등 온라인 시장과 모바일 시장이 급격하게 성장함에 따라 이에 따른 장애 소식이 끊이지 않고 전해지고 있습니다.
그렇다면, 우리는 이런 장애들을 어떻게 대비할 수 있을까요?
웹∙앱 부하테스트 (성능 진단) 및 컨설팅 안은 웹∙앱 부하테스트(성능 진단 테스트) 진행 과정과 이를 기반으로 어떻게 컨설팅을 진행하고 있는지 소개하고, 나아가 관련 장애들을 대비할 수 있는 방법에 대해 설명합니다.
(공유드리는 파일은 slideshare에 업로드되었던 웹∙앱 부하테스트 성능 진단 및 컨설팅 안을 업데이트한 최신 본입니다.)
웹∙앱 부하테스트 (성능 진단) 및 컨설팅 자료는 아래와 같이 구성되어있습니다.
• 웹∙앱 성능을 진단하고 문제에 대한 원인 분석 및 개선방향을 제시합니다.
• 컨설팅 안에는 여러 실 성능 진단을 예시로 들고 이에 대한 원인 분석 및 개선방향을 도
출한 내용이 포함되어 있습니다.
1. 앱 성능 진단
• 앱 진단 절차
• 앱 진단 상세 내용
2. 웹 서버 성능 진단
• 웹 진단 절차
• 웹 진단 방향
3. 부하 테스트
• 현 테스트 시나리오 분석
• 테스트 시나리오 보완 방법
• 부하 테스트 진행 방안
• 부하 테스트 전략
• 클라우드 기반 테스트 방안
모바일 성능 모니터링, 웹 서버 성능 진단 및 부하테스트 컨설팅에 관심이 있으신 분은 아래 연락처로 연락해주시면, 전문 컨설턴트가 안내해드리겠습니다.
hhjung@onycom.com l 02-6395-7722
[오픈소스컨설팅]Day #1 MySQL 엔진소개, 튜닝, 백업 및 복구, 업그레이드방법Ji-Woong Choi
MySQL 소개
간략한 소개
version history
MySQL 사용처
제품 군 변화
시장 변화
MySQL 구성
MySQL 클라이언트 / 서버 개념
클라이언트 프로그램
MySQL 설치
MySQL 버전
MySQL 설치
MySQL 환경 설정
환경설정, 변수 설정
MySQL 스토리지 엔진 소개
MySQL tuning 소개 및 방법
데이터 백업/복구 방법
백업
복구
MySQL Upgrade
An introduction to the advantages of the features of JMeter 4.0. In addition, I will talk a little bit about the way that a real project applies it for continuous integration on TeamCity to get the test result in every day
Load Testing Best Practices: Application complexity is increasing, yet the stringent requirements for web performance is increasing exponentially. Learn more about the three major types of load testing, determine which you need and how to conduct them.
2022년 11월 30일 코엑스에서 개최한 베스트콘2022(Better Software Testing Conference 2022)에서 발표한 강연 자료입니다.
대규모 장애를 막기 위해 소프트웨어/품질 엔지니어가 알아야 할 내결함성의 개념과 설계 기법을 공유드립니다.
생생한 강연 영상으로 확인해 보세요!
https://youtu.be/OLsv7oG0VPo
JMeter is an Apache Jakarta project that can be used as a load testing tool for analyzing and measuring the performance of a variety of services, with a focus on web applications.
www.silenceit.ca
MySQL Administrator
Basic course
- MySQL 개요
- MySQL 설치 / 설정
- MySQL 아키텍처 - MySQL 스토리지 엔진
- MySQL 관리
- MySQL 백업 / 복구
- MySQL 모니터링
Advanced course
- MySQL Optimization
- MariaDB / Percona
- MySQL HA (High Availability)
- MySQL troubleshooting
네오클로바
http://neoclova.co.kr/
지브라프린터 Zebra ZE500시리즈 열전사감열 RFID프린터엔진 오토라벨러엔진 바코드프린터엔진 매뉴얼HION IT
지브라의 새로운 ZE500™ 시리즈는 OEM 바코드 인쇄 엔진에 대한 혁신적인 접근 방식을 채택했습니다.
Zebra ZE500 시리즈 바코드 프린터 엔진은 광범위한 설문 조사를 활용하여 디자인, 사용 편의성, 서비스 및 통합 용이성에 중점을 두고 중요한 자동라벨링 업무에 중단없이 작동하도록 설계되었습니다.
우아한 디자인의 ZE500 바코드 프린터 엔진은 유지 보수를 단순화하고 유지 보수에 대한 가동 중단 시간을 획기적으로 줄여주며 3개의 롤러는 모두 프린터의 전자 장치에 접근할 필요없이 수 분 만에 교환 할 수 있습니다.
와이드 오픈 프린트 헤드는 청소 및 교체를 단순하게하며 퀵 체인지 모듈 식 드라이브 시스템은 프린터 수리 시간을 줄입니다.
확장된 RFID 기능은 보다 향상된 추적 성능을 제공하여 운영 효율성을 향상시킵니다.
리본 교체와 같은 일상적인 작업은 매우 간단합니다 (두 인쇄 폭 모두 동일).
새로운 그래픽 LCD 디스플레이는 장치에서 분리할 수 있으며 사용 편의성을 위해 응용 프로그램에 적합한 위치에 재배치 할 수 있습니다.
인쇄 및 적용할 기계와 쉽게 통합할 수 있으며 먼지와 물에 대한 내성이 뛰어납니다.
확장된 연결 포트 및 어플리케이터 포트의 향상된 소프트웨어 제어 기능은 통합 유연성을 한층 향상시킵니다.
Resolution: 203 dpi (8 dots per mm); 300 dpi (12 dots per mm)
Rotatable front panel display (0,180)
16MB SDRAM memory, 64MB Flash Memory
Available in right and left hand configurations
ZebraNet 10/100 Print Server (Internal)
Embedded ZebraLink WebView™and Alert features
Real Time Clock
Applicator interface - provides status and control signals for applicators
Communications via serial RS-232, IEEE 1284 bidirectional parallel interface with auto detect, and USB 2.0 port
Full function graphic front panel & large multilingual back-lit LCD display with user programmable password protection
Thin film print head with E3® Element Energy Equalizer
Dual media sensors, transmissive and reflective, selectable through software or front panel
ZPL® or ZPL II® programming language, selectable through software or front panel
XML-Enabled Printing ? allows XML communications from today's enterprise systems for barcode label printing
32 bit 133 MHz RISC processor
Zebra printer driver for Windows 7, XP, Vista, 2008, and 2003 operating systems
Advanced media counters
PRINTER SPECIFICATIONS
ZE500-4™ :
Maximum print width : 4.1”/104 mm
Media specification :
Label and liner width: 0.625”/16 mm to 4.5”/ 114 mm
Minimum length with back feed: 0.5”/13 mm
Minimum length without back feed: 0.25”/6.5 mm
Minimum length in stream mode: 0.25”/6.5 mm
Maximum length: 39”/990 mm
Maximum continuous media print length: 150”/3,810 mm
Ribbon width: 1”/25.4 mm to 4.2”/107 mm
Resolution : 203 dpi/8 dots per mm or 300 dpi/12 dots per mm
Maximum print speed : 12”/305 mm per second (203 and 300 dpi)
ZE500-6™ :
Maximum print width : 6.6”/168 mm
Media specification
Label and liner width : 3”/76 mm to 7.1”/180 mm
Minimum length with back feed : 3”/76 mm
Minimum length without back feed : 1”/25.4 mm
Minimum length in stream mode : 1”/25.4 mm
Maximum length : 39”/990 mm
Maximum continuous media print length : 150”/3,810 mm
Ribbon width : 3”/76 mm to 7.1”/180 mm
Resolution : 203 dpi/8 dots per mm or 300 dpi/12 dots per mm
Maximum print speed
12”/305 mm per second (203 dpi)
10”/254 mm per second (300 dpi)
>하이온아이티
주소 : 서울 금천구 가산디지털2로 165, 1304호 (백상스타타워2차)
대표번호 : 02-2038-0018 / 이메일 : hion@hionit.com
홈페이지 : http://hionsmart.com
source : http://www.opennaru.com/redhat/jboss/
세계 최고의 오픈소스 미들웨어 JBoss EAP
JBoss EAP ( JBoss® Enterprise Application Platform )는 클라우드와 컨테이너를 포함한 모든 IT 환경에서 엔터프라이즈급의 보안, 성능, 확장성을 제공합니다.
Java EE 표준을 지원하는 세계에서 가장 많이 사용되는 오픈 소스 웹 어플리케이션 서버 입니다.
오픈 소스 소프트웨어이기 때문에 도입 비용이 저렴할 뿐만 아니라, 레드햇의 높은 기술력으로 기업용 미들웨어에 적합한 품질과 기술지원을 제공합니다.
라이선스 형태는 GNU Lesser General Public License (LGPL) 한가지 이지만, 배포 버전은 커뮤니티 버전(WIldfly)와 엔터프라이즈 버전(JBoss EAP) 두가지 입니다.
엔터프라이즈 버전인 JBoss EAP는 레드햇과 유료 서브스크립션 계약을 맺음으로써 사전에 인증된 JBoss 소프트웨어 최신 패치 파일과 업그레이드을 할 수있습니다.
회사 내부 교육(소개)용으로 만든
현재 팀이 일하고 있는 프로세스를 정리한 자료 - 의료 소프트웨어 제품
- Dev & Test Process(V-Model)
1) Review / Planning
2) Test Execution
3) Other types of Testing
4) Release / Operation
성능 진단 및 컨설팅 제안서입니다.
모바일 성능 모니터링, 모바일 자동화 테스트, 웹 서버 성능 테스트를 합리적인 가격에 컨설팅 해 드립니다.
⁍ 업데이트된 최신본 성능 진단 및 컨설팅 제안서 확인해 보세요!
https://www.slideshare.net/IMQAGroup/imqa-performance-consulting
AgitarOne은 Java로 개발중인 Eclipse 프로젝트에 자동화된 단위 테스트의 환경을 제공하여 테스트 시간을 대폭 단축 시켜 개발 비용을 절감하게 하며, 작성된 소스 코드들이 실질적으로 수행되는지 명확히 파악할 수 있도록 하여 소스 코드의 품질을 향상시켜 줄 수 있는 Java 개발자의 단위 테스트 자동화 솔루션 입니다.
예전에 인턴하면서 프로젝트해서 만든 자료인데 공유하고 싶어서 올립니다.
한국어로된 자료가 별로 없더라구요.
많은 레퍼런스 보고 만든 문서인데 혹시 필요하신분 있으면 참고하세요.
물론 이건 표준이고 현실에서는 표준을 따르지 않을 때도 많습니다.
프로젝트마다 테스트 강도를 조절하는 것이 좋다고 생각합니다.
지브라프린터 Zebra 105SLPlus 열전사감열 산업용 바코드프린터 매뉴얼HION IT
지브라, Zebra 105SL Plus 바코드프린터는 인기 장수 모델인 105SL 프린터의 업그레이드로 올 메탈 프린터에 큰 LCD 창이 장착되어 있습니다.
ZM400 프린터를 사용하기에 열악한 환경이나 XI급의 성능을 원하지만 예산이 부족한 경우 추천할 수 있는 바코드프린터로 고성능 인쇄가 가능하며 비용대비 성능이 향상되어 물류창고업 또는 제조산업, 화물운송, 리테일 산업에 매우 적합합니다.
전면에 대형 다국어 백라이트 LCD가 장착되어 향상된 사용성
우수한 인쇄 품질을 위한 박막 헤드 적용
8 MB 플래시메모리
RS-232C 및 양방향 병렬 자동 감지 포트
USB 2.0
듀얼 미디어 센서
ZebraNet ® 내장형 10 / 100 프린터 서버
STANDARD FEATURE
Print Methods : Direct thermal and thermal transfer
Resolution : 203 dpi or 300 dpi
Full-function front panel and large multilingual back-lit LCD display -with user-programmable password protection
Thin film printhead with Element Energy Equalizer™ (E3™) for superior print quality
8 MB Flash memory-including 2 MB user-available non-volatile memory storage for downloadable objects
Serial RS-232 and bi-directional parallel ports-with auto detect
USB 2.0
Dual media sensors-transmissive and reflective, selectable through software or front panel
Internal ZebraNet 10/100 Print Server-supports 10Base-T, 100Base-TX, and fast Ethernet 10/100 auto-switching networks.
PRINTER SPECIFICATIONS
Resolution : 203 dpi (8 dots/mm)/ 300 dpi (12 dots/mm)
Memory : Standard - 16 MB SDRAM; 8 MB Flash
Print width : 4.09" (104 mm)
Print length (with standard memory) : 203 dpi : 105"/3810 mm, 300 dpi (optional) : 100"/2540mm
Print speed : 203 dpi : 12"/305 mm per second, 300 dpi : 10"/254 mm per second
MEDIA CHARACTERISTICS
Media types : continuous, die-cut, or black mark, notch
Media thickness (label and liner) : 0.003"/0.076 mm to 0.012"/0.305mm
Maximum media roll size : 8.0"/203 mm O.D on a 3"/76 mm I.D. core
Media width (label and liner) : 0.79"/20 mm to 4.5"/114 mm
Maximum non-continuous label length : 39"/991 mm
RIBBON CHARACTERISTICS
Standard Lengths : 1476'/450 m or 984/300 m
Provides 2:1 and 3:1 media roll to ribbon ratios
Maximum ribbon roll size : 3.2'/81.3 mm OD on a 1.0'/25.4 mm I.D. core
Ribbon wound coated-side out
Ribbon width : 0.79'/20 mm to 4.33'/110 mm
PHYSICAL CHARACTERISTICS
Width : 10.31" (261.9 mm)
Height : 15.5" (393.7 mm)
Depth : 20.38" (517.5 mm)
Weight : 50 lbs (22.7 kg)
PROGRAMMING LANGUAGES
Core programming languages : XML,ZPL I, ZPL II
>하이온아이티
주소 : 서울 금천구 가산디지털2로 165, 1304호 (백상스타타워2차)
대표번호 : 02-2038-0018 / 이메일 : hion@hionit.com
홈페이지 : http://hionsmart.com/
지브라프린터 Zebra ZT220 ZT230 열전사감열 산업용 바코드프린터 매뉴얼HION IT
S4M 바코드프린터의 장점을 바탕으로 고객으로부터의 다양한 의견 수렴을 통하여 출시된 새로운 ZT200 시리즈 바코드프린터는 우수한 공간 절약형 디자인, 손쉬운 설정, 직관적인 사용자 운영 그리고 편리한 서비스 및 유지보수 등의 특징을 가지고 있습니다.
ZT200 바코드프린터 시리즈는 바코드 기술의 신규 도입부터 기존 바코드프린터 모델의 업그레이드까지, 다양한 라벨링 어플리케이션에 적합한 탁월한 선택이며, 이 혁신적인이고 새로운 프린터는 많은 사용자에게 혜택을 제공할 것입니다.
지브라 ZT200 바코드프린터 시리즈는 효율적인 디자인과 작은 크기로 Stripe와 S4M 모델 보다 물리적 공간을 더욱 작게 차지하며 최소한의 운영자 교육, 주요 구성요소에 대해 공구가 필요없는 유지보수 서비스를 제공합니다.
또한 기존 시스템과의 완벽한 호환성을 제공하기에 IT 담당자는 다운타임을 최소화하면서 새로운 프린터를 운영할 수 있습니다.
ZT220
지브라의 가장 저렴한 탁상용 프린터
충격에 강하고 견고하여 오래 사용할 수 있는 폴리머 케이스
300m 리본 용량
사용자가 간단하게 사용할 수 있는 3개의 조작 버튼
바코드라벨의 교체가 빈번하게 발생하는 작업에 이상적입니다.
ZT230
견고한 금속 케이스로 오래 사용할 수 있습니다.
가동 시간을 늘리고 리본 교환 횟수를 줄이기 위한 450m 리본 용량
화면 표시 내용이 그래픽으로 처리되어 바코드프린터 설정 및 제어가 편리함
바코드라벨의 교체가 좀 더 빈번하게 발생하는 작업에 이상적입니다.
지브라 ZT200 바코드프린터 시리즈는 고객의 다양한 의견과 고객의 프린팅 어플리케이션, 진화하는 비즈니스 요구와 운영상의 문제점에 대한 이해를 바탕으로 설계된 최고의 제품으로, ZT200 시리즈는 동급 프린터에서 일반적으로 찾을 수 없는 탁월한 성능과 특징을 제공합니다.
공간 절약형 디자인
제한된 좁은 공간에 적합한 작은 설치 공간과 효율적인 설계
업무 공간을 최대화하며 좁은 공간에도 적합한 독특한 접이식 도어의 공간 절약형 디자인(개방 공간 102mm/4” 필요)
빠른 설치 및 통합
구형 Stripe 및 S4M 모델의 완벽한 후속 모델
다중 연결 옵션: 병렬, 10/100 이더넷, 802.11b/g/n 무선
아이콘 기반의 상태 LED로 프린터 상태를 쉽고 즉각적으로 파악
직관적이고 손쉬운 미디어 장착
복잡한 소모품 장착을 간소화하는 측면 장착 디자인
처음 사용자도 리본 및 미디어를 장착할 수 있도록 색깔로 표현된 시각적 안내 제공
미디어를 통해 보이는 발광형 이동식 센서로 간단하게 센서 위치 조정
인쇄 품질
미세 조정으로 더 나은 인쇄 정확도를 보장하도록 제작
선명하고 깔끔한 텍스트 및 바코드 - 좁은 미디어에서도 가능
Zebra 신뢰성과 내구성
경공업 및 상업 환경에 적합하도록 제작
Energy Star® 인증
최소한의 유지보수로 최적의 성능을 제공하도록 설계된 드라이브 시스템
간소화된 사용성
플래턴과 프린트헤드를 도구없이 쉽게 제거함으로써 간단히 청소와 교체 가능
손쉽게 교체 가능한 연결 옵션으로 신속한 프린터 교체 및 업그레이드 가능
일반적인 도구 3개로 기본 서비스 가능
PRINTER SPECIFICATIONS
Resolution ;
8 dots per mm/203dpi
12 dots per mm/300dpi (optional)
Memory : Standard / 128MB flash (58MB user-available), 128MB DRAM
Print width ;
104mm/4.09"
Minimum: 0.75"/19.4mm
Print speed : 152mm/6" per second
Media sensors : Transmissive and reflective sensors
Media characteristics ;
Maximum label and liner width : 114mm/4.5"
Maximum non-continuous label length : 991mm/39"
Media width : 19.4mm/0.75" to 114mm/4.50"
Print length ;
203dpi : 3,988mm/157"
300dpi : 1,854mm/73"
Maximum media roll size ;
203mm/8.0" O.D on a 76mm/3.0" I.D. core
152mm/6.0" O.D. on a 25mm/1.0" I.D. core
Media thickness : 0.076mm/0.003" to 0.25mm/0.010"
Media types : Continuous, die-cut, notch, black-mark
>하이온아이티
주소 : 서울 금천구 가산디지털2로 165, 1304호 (백상스타타워2차)
대표번호 : 02-2038-0018 / 이메일 : hion@hionit.com
홈페이지 : http://hionsmart.com
지브라프린터 Zebra ZT410 ZT420 열전사감열 산업용 바코드프린터 매뉴얼HION IT
지브라프린터 ZM400 후속 모델로 지브라 ZT400 시리즈 (ZT410, ZT420), 바코드프린터는 다양한 어플리케이션에서 장시간 사용이 가능 하도록 설계된 뛰어난 산업용프린터로 귀사의 중요 업무를 효율적으로 지원 할 것입니다.
ZT400 시리즈 (ZT410, ZT420), 바코드프린터는 현장에서 입증된 Z Series의 신뢰성을 바탕으로 인쇄속도 인쇄품질 및 네트워크 연결 옵션을 더욱 개선하였습니다.
또한 사용자 편의성을 고려하여 디자인된 ZT400 시리즈 바코드프린터는 직관적인 아이콘 기반의 LCD 그래픽 사용자 인터페이스를 제공하며 소모품을 간편하게 장착할 수 있습니다.
통신연결은 USB, 직렬, 이더넷 및 블루투스 포트를 기본으로 제공하며, 확장된 RFID 기능은 더욱 강력한 추적 능력과 상세한 가시성을 제공합니다.
ZT400 시리즈 (ZT410, ZT420), 바코드프린터는 4인치, 6인치 모델로 제공되며, 귀사의 바코드프린터 투자에 현재와 미래의 요구를 항상 충족시킬 수 있도록 광범위한 고급 기능을 표준으로 제공합니다.
외관은 전체가 금속 프레임과 접이식 도어로 구성되어 공간이 제한된 환경에 적합하도록 설계되었습니다.
강력한 멀티플렛폼 SDK (Software Development Kit)와 소프트웨어 어플리케이션이 결합된 혁신적 운영체제인 제브라의 Link-OS 환경을 통해 전세계 어디에서나 통합, 관리, 유지보수가 용이합니다.
ZT410
Maximum print width : 4 인치
Maximum ribbon length : 450 m
Maximum print speed ; 14 ips
User Interface : LCD
Print resolution : 203, 300, 600 dpi
Printer control language : ZPL, EPL, others
ZT420
Maximum print width : 6 인치
Maximum ribbon length : 450 m
Maximum print speed ; 12 ips
User Interface : LCD
Print resolution : 203 and 300 dpi
Printer control language : ZPL, EPL, others
어플리케이션 유연성
폭넓은 범위의 사용가능한 미디어와 미디어 배송 옵션으로 프린팅 준비성 확대
최종 사용자가 설치 가능한 미디어 핸들링 옵션으로 현재와 미래의 비지니스 요구에 맞게 프린터 커스터마이징 가능
직렬, USB, 이더넷 및 블루투스의 기본 제공 및 기타 연결 옵션을 위한 두개의 개방형 미디어 슬롯
설치 및 사용 용이성을 고려한 확장된 RFID 기능
고해상도 인쇄기능으로 소형 바코드라벨 어플리케이션에서 고품질의 결과물 보장
간편한 통합
USB 호스트 포트의 장착으로, 미러링을 통한 USB 플래시 드라이브 데이터의 간편한 전송과 확장된 매핑 드라이브 메모리 기능을 활용하여 간단한 프린터 설정 가능
Virtual Device 앱을 통해 ZPL 및 EPL 이외 주요 래거시 및 경쟁사 프린터 언어를 지원함으로 미래에 대비한 투자 가능
용이한 조작
Dynamic QR 코드로 프린터 오류의 신속한 해결을 위한 온디맨드, 웹 기반의 지원 제공
Print Touch 를 지원하는 Link-OS 프린터는 NFC(Near Field Communicatrion)를 사용하여 웹 페이지 실행, 사용법에 관한 동영상과 제품 지원에 관한 지브라의 광범위한 지식 기반에 편리하게 엑세스
미디어 및 리본 경로의 조명으로 어두운 환경에서도 프린터 내부 확인 용이
간단한 관리
지브라의 Link-OS 환경으로 어느 곳에서나 프린터의 모니터, 관리 및 유지보수가 가능한 진보된 기능 제공
Clould Connect를 이용하여 인쇄 및 기기 관리를 위한 Link-OS 지원 프린터와 클라우드의 안전하고 직접적인 상호 작용 가능
Profile Manager를 통해 전세계 어디에서든 단일 프린터, 복수의 프린터, 또는 네트워크상의 모든 Link-OS 지원 프린터를 편집 및 관리
PRINTER SPECIFICATIONS
Resolution :
203 dpi/8 dots per mm
300 dpi/12 dots per mm (optional)
600 dpi/24 dots per mm (optional for ZT410 only)
Memory : 256 MB SDRAM/ 512 MB on-board linear Flash memory
Maximum Print Width : 4.09"/104 mm
Maximum Print Speed : 14 ips/356 mm per second
Media Sensors : Dual media sensors - transmissive and reflective
Media Characteristics - Media web width (label and liner):
1.00"/25.4 mm to 4.5"/114 mm tear/cutter
1.00"/25.4 mm to 4.25"/108 mm peel/rewind
Maximum non-continuous label length: 39"/991 mm
Print Length :
203 dpi : 157”/3988 mm
300 dpi : 73”/1854 mm
600 dpi : 39”/991 mm
Maximum Media Roll Size : 8.0"/203 mm O.D. on a 3"/76 mm I.D. core
Media Thickness : 0.0023"/0.058 mm to 0.010"/0.25 mm
Media Types : Continuous, die-cut, notch, black-mark
>하이온아이티
주소 : 서울 금천구 가산디지털2로 165, 1304호 (백상스타타워2차)
대표번호 : 02-2038-0018 / 이메일 : hion@hionit.com
홈페이지 : http://hionsmart.com
Similar to Performance test using_j_meter_ver1.2 (20)
2. 2
Table of Contents
1. jMeter 설치 ................................................................................................................... 5
1.1. jMeter 개요 및 활용 방안.............................................................................................. 5
기능 점검 ...................................................................................................................... 5
수용량 측정.................................................................................................................... 5
부하 테스트.................................................................................................................... 5
1.2. jMeter 설치 .............................................................................................................. 5
jMeter 설치 및 실행.......................................................................................................... 6
1.3. jMeter 플러그인 설치 .................................................................................................. 6
2. jMeter TestPlan 작성 절차 ................................................................................................. 7
2.1. jMeter UI ................................................................................................................. 7
2.2. TestPlan 구성 요소 및 용어 ........................................................................................... 8
Thread Groups (Users)....................................................................................................... 9
Sampler (Unit Test) .......................................................................................................... 9
Config Element ............................................................................................................... 9
Listener (Report) ............................................................................................................. 9
2.3. TestPlan 작성 절차 ..................................................................................................... 9
TestPlan 기본정보 입력 ..................................................................................................... 9
Config Element 추가 .......................................................................................................10
HTTP Request Defaults ............................................................................................. 10
HTTP Header Manager .............................................................................................. 10
HTTP Cookie Manager............................................................................................... 11
Thread Group 추가 .........................................................................................................11
Listener 추가 ................................................................................................................12
View Results Tree.................................................................................................... 12
Summary Report ..................................................................................................... 13
View Results in Table ............................................................................................... 14
Sampler 추가 ................................................................................................................14
3. OpenAPI 테스트 계획......................................................................................................16
테스트 목적 ....................................................................................................................16
테스트 개요 ....................................................................................................................16
기능 테스트 계획 (Functional Test Plan)..................................................................................16
기능 테스트 구성 ...........................................................................................................16
User Defined Variables ....................................................................................................16
Thread Group ...............................................................................................................18
Config Element .............................................................................................................18
HTTP Request Sampler ....................................................................................................20
사용자 등록 ........................................................................................................... 20
사용자 인증 ........................................................................................................... 21
JSON Assertion..............................................................................................................22
JSON Path Assertion................................................................................................. 22
JSON Path Extractor................................................................................................. 23
BeanShell Assertion.................................................................................................. 23
Listener (View Results Tree) .............................................................................................24
부하 테스트 계획 (Load Test Plan) .........................................................................................25
테스트 시나리오 ............................................................................................................25
부하 테스트 구성 ...........................................................................................................25
CSV Data 생성...............................................................................................................26
CSV Data Set Config........................................................................................................26
Thread Group ...............................................................................................................27
Timer (Constant & Uniform Random)...................................................................................28
Listener (Report) ...........................................................................................................29
3. 3
Aggregate Graph (or Aggregate Report) ......................................................................... 29
Response Time over Time .......................................................................................... 30
Transactions per Seconds .......................................................................................... 31
4. 기능 및 부하 테스트 수행.................................................................................................32
준비 사항 .......................................................................................................................32
기능 테스트 수행 절차........................................................................................................32
jMeter 실행..................................................................................................................32
Test Plan 실행 (기능) ......................................................................................................33
실행 결과 검토 ..............................................................................................................33
부하 테스트 수행 절차........................................................................................................33
CSV generator 실행 ........................................................................................................34
Test Plan 실행 ..............................................................................................................34
jMeter GUI 모드 실행 ......................................................................................................36
성능 리포트 작성 ...........................................................................................................36
5. 5
1. jMeter 설치
jMeter 어플리케이션과 추가 플러그인(plugin)을 설치하는 절차를 요약하였다.
1.1. jMeter 개요 및 활용 방안
jMeter 는 부하 테스트(load test) 및 성능 평가 (measure performance)를 위해 설계된 자바 기반의 오픈소스
데스크톱 어플리케이션이다. jMeter 를 이용해 정적/동적 웹 컨텐츠, FTP, mail, 데이터베이스, NoSQL 등의 성능
분석을 수행할 수 있다. Open API 서버에 대한 기능 점검 (단위 테스트), 수용량 측정 및 부하 테스트에 적용한다.
기능 점검
Open API 의 사용자 정보, 게임 정보, 채널 정보 및 컨텐츠 정보 서비스에 포함된 각각의 API 에 대한 정상 동작
유무를 테스트하는 테스트 케이스를 작성한다. 기능 테스트의 목적은 ‘지속적인 품질 확보’이다.
Open API 기능 추가 및 개선, 버그 수정에 따른 변경 시, 자동화된 테스트 실시
Development, Stage, Product 환경으로 이행(transfer) 시 정상 배포 여부 판정
수용량 측정
사용자의 서비스 사용 시나리오를 예측하여 시나리오 기반의 테스트 케이스(혹은 계획)을 작성하고, 이를 이용해
서비스 환경을 시뮬레이션(simulation) 한다. 다수의 가상 사용자(virtual user)가 접속하여, 소규모 서버에서 수용
가능한 동시 사용자 수(혹은 적정 사용자 수)를 산출한다. 수용량 측정의 목적은 ‘시스템 확장 및 운영 계획’ 수립을
위한 기초 자료 확보이다.
사용자의 서비스 사용 시나리오 예측
예상 시나리오 기반의 테스트 계획 작성
개발 및 stage 서버 대상의 동시 접속 및 서비스 운영 테스트 실시
테스트 결과를 이용해 수용 가능량, 자원 소모량 (CPU, 메모리, 디스크)을 측정한다.
시뮬레이션 결과를 바탕으로 향후 서버 확장 및 스케일 자동화 (auto-scale) 계획을 수립한다.
부하 테스트
부하 테스트의 목적은 하드웨어, 소프트웨어, 네트워크 등 서버 아키텍처 전반에 걸친 안정성 점검, 취약점 분석 및
스케일 자동화의 모의 테스트 수행이다. jMeter 를 다수의 에이전트 서버에 설치한 후, 동시에 수백/수천에 이르는
사용자 접속을 시도하여, 시스템 응답 성능과 서버 자원의 상태를 모니터링 한다. 부하 테스트의 수행 방식은
수용량 측정과 동일하나, 의도적으로 과부하 상태를 유도하고 그에 따른 서버 상태를 확인한다는 점이 다르다.
또한 부하 테스트 시에는 응답 속도 등 성능 측정 보다는 취약점(개선점)을 찾는데 주력한다.
1.2. jMeter 설치
jMeter 는 오픈 소스이며, 아파치 홈페이지에서 다운로드 받을 수 있다. Open API 가 RESTful 방식이고 응답
데이터 형식이 JSON 이므로, JSON 데이터 해석(parsing)을 위한 추가 플러그인을 설치해야 한다.
6. 6
jMeter 설치 및 실행
jMeter 는 GUI 및 CLI 를 모두 제공하며, jMeter 테스트 계획(test plan)을 작성하거나, 수동으로 테스트를 수행하기
위해서 개발 PC 에 jMeter 를 설치해야 한다. 자동화된 테스트를 수행하거나, 부하 테스트를 실시할 경우에는 서버
상에서 jMeter 를 설치한다.
jMeter 를 개발 PC 에 설치하기 이전에 JDK 1.6 이상의 버전을 PC 에 설치해야 한다.
http://jmeter.apache.org/download_jmeter.cgi 에서 jMeter 압축 파일을 다운로드 받는다.
적절한 폴더 위치에 압축 파일을 해제한다.
${JMETER_HOME}/bin/jMeter.bat 파일을 실행하면 jMeter GUI 가 실행된다.
Report /
Graph
DBMS
Amazon Cloud
Web / WAS
Remote Client
jMeter #1
jMeter #2
jMeter #n
Run Stress Tess
HTTP Requests
HTTP Responses
1.3. jMeter 플러그인 설치
Open API 의 응답 데이터를 파싱(parsing)하고, 서비스의 정상 수행 여부를 판단하기 위해 JSON Path Assertion
플러그인을 설치해야 한다. jMeter 플러그인을 사용하기 위해서는 jMeter version 2.8 이상을 설치해야 한다.
http://jmeter-plugins.org/#/ 사이트에 접속한다.
‘Extras with Libs Set’ 을 다운로드 한다.
압축 파일을 해제하면, lib 폴더 안에 jar 파일들이 포함되어 있으며 jar 파일들을 jMeter 홈 디렉토리
아래에 위치한 lib 폴더에 넣는다.
7. 7
2. jMeter TestPlan 작성 절차
jMeter 내에서 테스트 케이스(test case)를 작성하는 절차와 jMeter 기능들에 대한 간략한 설명, 테스트 케이스 작성
절차를 이해하는데 필요한 jMeter 용어를 정리하였다.
2.1. jMeter UI
jMeter 기본 UI 내에서 기본적으로 알아야 할 항목들을 요약하였다.
① Start TestPlan
TestPlan 을 실행한다. TestPlan 내에 포함된 모든 테스트 케이스를 실행하며, 수행 결과를 기록한다. 테스트
케이스를 작성 완료한 후 시험하거나, 이전에 작성된 TestPlan 을 로드(load)한 후 재실행할 때 사용한다.
② Clear output
TestPlan 수행 결과를 지운다. 테스트를 반복 수행하거나 TestPlan 이 변경되었을 때, 이전 테스트 결과를
지우기 위해 사용한다.
③ Error / Warning count
직전 TestPlan 수행 결과에서 오류가 발생한 테스트 케이스 개수를 표시한다. 아이콘을 클릭하면 logViewer
① Start TestPlan ② Clear output ③ Error/Warning count
8. 8
패널이 표시된다.
jMeter UI 좌측 패널에는 ‘TestPlan’과 ‘WorkBench’가 표시된다.
① TestPlan
jMeter 테스트 케이스(혹은 시나리오)에 대한 전반적인 설정을 포함하는 영역이다.
② WorkBench
워크벤치는 계속 사용하지 않는 임시 테스트 케이스를 작성하고 실험하기 위한 영역이다.
TestPlan 에 테스트 케이스들을 입력한 예시는 아래와 같다.
2.2. TestPlan 구성 요소 및 용어
테스트를 수행하기 위한 전반적인 설정 및 개별 테스트 케이스는 TestPlan 에 설정 혹은 추가한다.
테스트 케이스를 작성하기 위해 추가해야 하는 필수(기본) 구성 요소들은 ‘Thead Groups (Users)’, ‘Config Elements’,
‘Sampler’ 및 ‘Listener’ 이다. 나머지 구성 요소들을 좀 더 정교한 테스트를 수행하기 위해 설정한다.
9. 9
Thread Groups (Users)
Thead Groups 를 달리 표현하자면, 가상 사용자(virtual user)이다. 실제 사용자가 서비스(혹은 서버)를 호출하는
행위를 스레드가 모의 수행하는 것이다. 테스트를 실행하는 횟수, 주기, 동시에 실행되는 스레드 개수 등을 설정할
수 있다. TestPlan 작성 시 먼저 스레드를 생성하고, 스레드 아래에 sampler 들을 추가하게 된다.
Sampler (Unit Test)
사용자가 서비스를 실행하는 행위를 소프트웨어적으로 모방하는 것이며, 개별 테스트 케이스 혹은
액션(action)이라고 정의할 수 있다. HTTP 요청, TCP 통신, JDBC 쿼리 등 다양한 방식으로 서비스를 실행할 수
있는 sampler 들이 제공된다.
Config Element
테스트를 수행하기 위한 각종 환경 변수, 기본 값 등을 지정할 수 있다. 설정할 수 있는 항목들은 서버 주소 및 포트,
쿠키 값, HTTP 헤더 기본 값 등이 있다.
Listener (Report)
테스트 수행 결과를 기록하고, 리포트를 생성하는 역할을 담당한다. 그래프, 테이블, 요약 등 다양한
리스너(listener)가 제공된다.
2.3. TestPlan 작성 절차
TestPlan 을 작성하는 절차를 요약하였다. 필수 요소들만으로 구성한 절차이므로, 추가적인 요소들을 반영해야 정밀한
테스트를 수행할 수 있다.
TestPlan 기본정보 입력
좌측 패널에서 TestPlan 을 선택한 후, 명칭 및 간단한 설명을 입력한다. 사용자 정의 변수들을 추가할 수 있다.
10. 10
Config Element 추가
테스트를 수행하기 위한 ‘공통 설정(Common configurations)’을 추가한다. 테스트에서는 ‘HTTP Request Defaults’,
‘HTTP Header Manager’, ‘HTTP Cookie Manager’ 등 3 가지를 설정한다.
HTTP Request Defaults
서버 주소 및 포트 번호, 요청 및 응답 시간 제한 값 등의 항목에 대한 기본 값(default value)를 설정할 수 있다.
HTTP Request Defaults 에서 설정한 값을 개별 sampler 에서 덮어 쓸(override) 수 있다.
HTTP Header Manager
HTTP 통신 헤더에 추가해야 하는 항목을 설정한다. Open API 를 요청하기 위해 ‘Content-Type’을 ‘application/x-
www-form-urlencoded’ 값으로 설정한다.
11. 11
HTTP Cookie Manager
세션(session)을 필요로 하는 테스트 케이스들을 위해 쿠키(cookie)를 설정한다.
Thread Group 추가
테스트 반복 횟수, 동시 접속 수 등을 설정하기 위해 Thread Groups 를 추가한다.
12. 12
Listener 추가
테스트 수행 결과를 집계하고 리포트를 생성하기 위해 Listener 를 추가한다.
View Results Tree
테스트 수행 결과를 트리(tree) 형태로 상세하게 검토할 수 있다. 테스트 유형에 상관없이 기본적으로 추가하는
것을 권장한다. 단점은 대규모 테스트를 수행했을 때, 로그가 너무 많아 개별 항목을 찾아보기 불편할 수 있다.
14. 14
View Results in Table
테스트 수행 시 발생한 개별 요청 수행 결과를 테이블 형태로 출력한다. 테스트 결과를 엑셀 등으로 내보낸 후 통계
등 후반 작업을 수행하고 싶을 때 적합하다.
Sampler 추가
마지막으로 테스트 케이스들을 추가한다. 개별 sampler 혹은 테스트 케이스는 호출하는 API 경로(path), 요청
인자(request parameters), 메소드(POST, GET, PUT 등) 등을 입력한다. POST 및 GET 메소드인 경우에는 요청
인자를 ‘Paramters’ 탭에 입력하고, PUT 메소드인 경우에는 Body Data 에 입력해야 한다.
POST 메소드인 경우, 아래와 같이 입력하면 된다.
16. 16
3. OpenAPI 테스트 계획
테스트 목적
Open API 테스트의 목적은 다음과 같다.
개발 진행 중 Open API 기능의 점검 및 오동작 유무 파악
유지보수 단계에서 기능 추가/변경 발생 시 전체 API 에 대한 기능 점검 자동화
부하 테스트(load test)를 통한 온라인 서비스 성능 측정 및 자원(resource) 계획 수립
테스트 개요
테스트 수행 도구는 오픈 소스 성능 테스트 도구인 jMeter 를 사용한다.
‘기능’ 및 ‘부하’ 테스트 계획을 구분하여 별개의 스크립트로 작성한다.
기능 테스트는 ‘Open API specification’을 참조하여 모든 온라인 서비스 API 기능을 점검한다.
기능 테스트 계획에는 개별 요청에 대한 요청/응답 데이터 및 정상 유무를 판단하는 Assertion 을 포함한다.
부하 테스트는 사용자의 컨텐츠 활용 시나리오를 예측하여, 시나리오 기반의 테스트를 수행한다.
부하 테스트는 성능을 분석하기 위해 TPS (Transaction per Second), 응답 시간 통계 등을 생성한다.
부하 테스트는 하나의 마스터(master)와 복수의 (slave)로 구성된 분산 테스트(Distributed Test)를 실시한다.
기능 테스트 계획 (Functional Test Plan)
기능 테스트 계획은 Open API (혹은 온라인 서비스)의 정상 동작 유무를 자동화된 스크립트로 검증하기 위해 작성한다.
기능 테스트 구성
기능 테스트 계획의 구성 요소는 User Defined Variables, Thread Group, Config Element, Sampler, Assertion,
Listener 등이다. Thread Group 혹은 가상 사용자(virtual user)는 1 회 실행하는 것으로 설정한다. Config
Element 는 서버 주소, HTTP 헤더 및 쿠키 설정을 포함한다. Sampler 는 Open API 개수만큼 생성하며, 각각의 API
정상 동작 유무를 판단하기 위해 Assertion 을 추가한다. Listener 는 모든 요청/응답 데이터를 점검해야 하므로,
‘View Results in Table’을 추가한다.
User Defined Variables
Test Plan 의 속성 화면에서 사용자 정의 변수를 선언한다. 사용자 정의 변수는 Sampler, Thread Group, Listener,
Timer 등 Test Plan 하위에 등록된 각종 요소(element)에서 참조할 수 있다. 사용자 정의 변수의 장점은 반복적으로
같은 값을 입력하는 수고를 줄여주고, 시스템 환경이 변경되거나, 테스트 대상 시스템이 변경될 때 손쉽게 대응할
수 있다는 점이다. 사용자 정의 변수에는 서버 주소, 게임 순번, 채널 순번, 컨텐트 ID 등의 항목을 선언한다.
17. 17
Name Value Description
server_addr p.ap-northeast-1.elb.amazonaws.com URL 생성을 위한 서버 주소이며, 테스트 대상 서버 IP
주소 혹은 도메인 명칭
context_root /gcapi URL 생성을 위한 API 최상위 경로이며, Open API root
path or context root
game_seq GMGW1404081503010001GMGW14040815
03010001
컨텐츠 조회 및 등록 테스트를 위한 게임 정보. 테스트
대상 DB 에 등록되어 있는 임의의 게임 순번 (40 bytes)
ch_seq NIGW1404201230500000NIGW1404201230
500000
채널 및 컨텐츠 조회 및 등록 테스트를 위한 채널 정보.
테스트 대상 DB 에 등록되어 있는 임의의 채널 순번 (40
bytes)
cid CDA01404250715330000CDA01404250715
330000
컨텐츠 및 덧글 조회를 위한 컨텐츠 정보. 테스트 대상 DB
에 등록되어 있는 임의의 컨턴츠 ID (40 bytes)
auth_key 12345678901234567890123456${__time(yy
yyMMddHHmmss)}
모바일 장치 인증(mobile device authentication key).
사용자 신규 등록을 위한 인증 키. 반복적으로 사용자
등록 시 ‘기존 사용자 오류(already exist error)’가
발생하는 것을 방지하기 위해 테스트 실행 시각을 이용해
매번 인증 키를 신규 발행한다.
nick_name test_user_${__time(yyyyMMddHHmmss)} 사용자 신규 등록에 필요한 닉네임(nickname).
반복적으로 사용자 등록 시, ‘닉네임 중복’ 오류가
발생하는 것을 방지하기 위해 테스트 실행 시각을 이용해
매번 닉네임을 신규 발행한다.
device_id 15bf269cbffecf55b904648bb1304a376cd308
01
컨텐츠 등록 및 조회를 위한 디바이스 ID
사용자 정의 변수 중에서 game_seq, ch_seq, cid 등은 대상 서버를 바꾸거나 데이터의 변경이 발생할 경우,
데이터베이스 내에서 테스트 입력 데이터를 샘플링(sampling)한 후 jMeter 사용자 정의 변수 값을 재설정해야 한다.
‘auth_key’ 및 ‘nick_name’ 변수는 테스트 수행 시마다 다른 값이 입력되어야 하기 때문에 jMeter ‘__time’ 함수를
이용해 테스트 실행 시각을 바탕으로 매번 다른 값이 생성되도록 한다.
18. 18
Thread Group
Number of Threads (users) 는 1, Ramp-up Period 및 Loop Count 는 1 로 설정한다. 기능 테스트는 모든 요청들이
정상 동작하거나 실패하는지 여부만을 확인하면 되기 때문에 반복 테스트를 수행할 필요가 없다.
Config Element
‘HTTP Request Defaults’, ‘HTTP Header Manager’, ‘HTTP Cookie Manager’ 등 3 가지 Config Element 를
설정한다.
Type Description
HTTP Request Defaults HTTP 요청(request) 시 필요한 기본 값들을 설정한다. 일반적으로 서버 주소, 포트 번호,
타임아웃(timeout) 등을 설정할 수 있다.
HTTP Header Manager HTTP 요청(request) 시, HTTP header 에 설정할 기본 항목들을 추가한다. 컨텐츠 타입,
에이전트 정보, 인코딩 타입(encoding type) 등을 설정한다.
HTTP Cookie Manager HTTP 요청 /응답에서 발생하는 쿠키(cookie)를 관리한다. 테스트 수행 중 서버에서 전송받은
쿠키를 보관하고, 이후 요청 수행 시 보관된 쿠키를 요청 패킷(packat)에 자동으로 설정해주는
기능을 제공한다. 필요하면, 쿠키 변수와 값을 기본 설정할 수 있다.
19. 19
HTTP Request Defaults 에는 ‘서버 주소’ (Server Name or IP)를 설정한다.
HTTP Header Manager 에는 ‘Content-Type’ 변수를 설정한다. ‘Content-Type’ 변수는 RESTful API 의 입력 데이터
형식을 정확히 지정해 서버에서 요청 인자 파싱(request parameter parsing) 오류가 발생하는 것을 방지하기 위한
것이다.
HTTP Cookie Manager 에는 ‘Clear cookies each iteration?’ 을 체크한다. 반복(iteration) 테스트를 수행할 때마다
쿠키를 초기화하는 것이다.
20. 20
HTTP Request Sampler
Open API 개수만큼 Sampler 를 추가한다. 필수 항목은 ‘Name’, ‘Method’, ‘Path’ 이며, 요청 입력 값이 존재할 경우,
‘Parameters’를 추가한다. 단, ‘Method’ 유형이 ‘PUT’ 인 경우에는 ‘Body data’에 요청 인자 값을 입력해야 한다.
Sampler 등록을 위한 API 정보는 ‘Open API 연동 규격서’를 참조한다.
기능 테스트를 위한 Sampler 들은 ‘사용자 등록’, ‘사용자 인증’ 및 기타 기능 테스트 순으로 등록해야 한다. ‘사용자
등록’은 임의의 인증 정보를 생성해 신규 사용자로 가입하는 것이며, ‘사용자 인증’은 신규 생성한 사용자로
정상적으로 로그인(login) 되는지 확인하는 것이다. 나머지 테스트를 인증 이후에 등록하는 이유는 대부분의
기능들이 로그인 상태가 아니면 정상 응답하지 않기 때문이다.
사용자 등록
사용자 등록 sampler 에서는 4 개의 필수 인자(parameter)를 등록한다. 만일, API spec 이 변경되어 필수 인자가
추가/삭제될 경우, 인자를 추가하거나 삭제해야 한다.
Name Value Description
auth_key ${auth_key} 사용자 정의 변수를 참조한다. 중복을 방지하기 위해
테스트 수행 시 마다, 매번 새롭게 생성한 값을 사용한다.
auth_code IMEI 인증 방식은 고정된 값을 사용한다.
device_id 15bf269cbffecf55b904648bb1304a376cd30801 디바이스 ID 는 고정된 값을 사용한다.
nick_name ${nick_name} 사용자 정의 변수를 참조한다. 중복 방지를 위해 매번
새롭게 생성한 값을 사용한다.
21. 21
사용자 인증
사용자 인증 sampler 에서는 ‘auth_key’ ‘auth_code’, ‘device_id’ 등 3 개의 인자를 설정한다.
Name Value Description
auth_key ${auth_key} 사용자 정의 변수를 참조한다. 중복을 방지하기 위해
테스트 수행 시 마다, 매번 새롭게 생성한 값을
사용한다.
auth_code IMEI 인증 방식은 고정된 값을 사용한다.
device_id 15bf269cbffecf55b904648bb1304a376cd30801 디바이스 ID 는 고정된 값을 사용한다.
22. 22
사용자 인증 후에, JSON Path Extractor 를 이용해 응답 JSON 데이터 내에서 ‘user_key’ 필드 값을 추출한다.
추출된 값은 ‘user_key’ 변수에 할당하고 이후 ‘사용자 정보 조회’ 등의 테스트 케이스에서 입력 값으로 사용한다.
JSON Assertion
Assertion 은 JSON 형식의 응답 데이터(response data)를 파싱(parsing) 한 후, 응답 코드를 체크하여 정상 유무를
판단한다. 정상 응답 코드가 단일 값일 경우에는 ‘JSON Path Assertion’을 이용하고, 정상 응답 코드가 두 가지
이상인 경우에는 ‘JSON Path extractor’를 이용해 응답 코드를 변수에 담고 ‘BeanShell Assertion’로 에러를
검출한다.
JSON Path Assertion
정상 상태인 응답 코드가 단일 값일 경우에는 ‘JSON Path Assertion’을 이용해 기능 테스트 결과를 판단할 수
있으며, JSON 응답 데이터에서 값을 추출하는 작업과 추출 값을 예상 값(expected value)과 비교하는 작업을
한번에 처리할 수 있다. 아래 예시는 응답 코드가 ‘000’ 인 경우 정상으로 판단한다.
23. 23
JSON Path Extractor
정상적인 처리에 대해 응답 코드가 하나 이상 반환될 경우, 먼저 ‘JSON Path extractor’를 이용해 JSON 응답
데이터에 포함되어 있는 값을 jMeter 변수에 할당한다. 아래 예시는 JSON 데이터의 ‘result_code’ 필드 값을 추출한
후, jMeter ‘result_code’ 변수에 할당한다.
BeanShell Assertion
‘JSON Path Extractor’에 의해 추출된 변수를 ‘BeanShell Assertion’을 이용해 검사한다. 아래 예시는 ‘result_code’
변수의 값이 ‘000’ 이거나, ‘000’ 인 경우 정상으로 판정하고, 아닌 경우 오류 메시지를 출력한다.
24. 24
Listener (View Results Tree)
기능 테스트를 위한 Listener 는 개별 요청 건의 정상 유무와 요청/응답 데이터를 점검할 수 있어야 하며, 수행
성능을 파악할 수 있는 것들은 제외한다. 필수적으로 포함해야 하는 Listener 는 ‘View Results Tree’ 이다.
25. 25
부하 테스트 계획 (Load Test Plan)
테스트 시나리오를 정의하고, 각각의 시나리오를 위한 테스트 계획(jMeter TestPlan script)를 작성한 후, BMT 서버
상에서 부하 테스트를 실시한다. 매 번 부하 테스트를 수행한 후, 테스트 수행 환경, 수행 인자(execution parameter),
결과를 포함한 보고서 등을 작성한다. 부하 테스트는 일회성에 그쳐서는 안되며, 기능 확장 및 변경, 서버 확장에 따라
지속적으로 보고서를 작성해야 한다. 이를 통해 변화에 대한 지속적인 평가, 장기 예측을 위한 기초 자료 수집 및 부하
관리 노하우 축적이 가능해진다.
부하 테스트와 기능 테스트의 차이점은 다음과 같다.
기능 테스트는 가상 사용자(virtual user) 수를 한 명으로 설정하고, 반복 횟수 또한 1 회로 제한한다. 반면에
부하 테스트는 복수의 사용자가 반복적으로 테스트를 수행한다.
기능 테스트에서는 Assertion 을 이용해 응답 데이터의 정상 유무를 검사하지만, 부하 테스트에서는 가급적
Assertion 을 포함시키기 않는다. (Assertion 을 많이 사용할수록, Assertion 수행으로 인한 지연 및 자원 소모
등으로 인해 부하 테스트의 측정 결과가 부정확해진다.)
기능 테스트에서는 수행 결과의 면밀한 분석을 위해 ‘Results in Tree’ 등 상세한 로그를 조회할 수 있는
Listener 를 사용하지만, 성능 테스트에서는 가급적 집계성(aggregate) Listener 들을 사용한다. 부하
테스트에서 정밀한 결과를 산출하는 Listener 를 사용하거나, Listener 의 종류를 많이 적용할수록 부정확한
결과가 만들어진다.
부하 테스트 시에는 복수의 서버를 이용한 원격 테스트를 수행하거나, CLI(Command Line Interface)를 이용한
배치 처리(batch processing) 방식이 적용될 수 있다. 대규모 서비스에 대한 성능 분석 시에는 원격 테스트가
필수이다.
테스트 시나리오
사용자들의 이용 패턴을 예측하여 시나리오를 세분화 한다. 사용자들을 서비스 미사용자, 컨텐츠 소비자 및 컨텐츠
생산자 그룹으로 구분하여, 그에 따른 테스트 계획을 작성한다.
사용자 그룹 부하 테스트 시나리오 요약
서비스 미사용자 신규 가입 회원 정보를 입력 하고, 닉네임(nickname) 중복 여부를 체크한 후,
로그인하여 기본 정보를 확인한다.
컨텐츠 소비자 로그인 및 브라우징 이미 가입한 사용자가 서비스에 로그인 한 후, 자신이 즐겨보는
컨텐츠를 구독하고, 컨텐츠에 대한 리액션(reaction) – 좋아요,
즐겨찾기, 댓글 쓰기 - 을 수행하는 과정이다.
컨텐츠 생산자 컨텐츠 업로드 컨텐츠를 생성하는 BJ 들이 녹화한 동영상과 메타 정보를 등록 및
편집하는 과정이다.
개별 시나리오는 행위 주체(action behavior)와 발생 빈도가 상이하기 때문에 별개의 테스트 계획으로 작성하고,
부하를 측정해야 한다.
부하 테스트 구성
부하 테스트는 기능 테스트와 ‘Thread Group’, ‘Assertion’ 및 ‘Listener’ 구성(설정)이 다르다. 임의의 사용자를
등록하기 위해 ‘CSV Data Set Config’, 사용자의 실제 서비스 사용을 모방(simulation)하기 위해 ‘Timer’를 추가한다.
부하 테스트 수행 시에는 Open API 의 정상 동작 유무가 테스트 관심사가 아니며, jMeter 자원 소모를 줄이고 측정
정확도를 높이기 위해 ‘Assertion’은 제거한다. Listener 는 수행 성능을 측정해 통계 및 그래프를 생성하는 것들을
사용한다.
26. 26
CSV Data 생성
부하 테스트 절차는 ‘5. CSV 데이터 생성’ 을 참조하면 된다.
CSV Data Set Config
부하 테스트 수행 시 임의의 사용자들을 신규 등록하고 로그인 하기 위해, 인증 키 (auth_key)와 닉네임
(nickname)을 일괄 생성한 CSV 파일을 입력 데이터로 사용한다.
CSV 파일 데이터 샘플은 다음과 같다. 인증 키 데이터는 40 bytes 이며, 닉네임의 최소 길이는 2 byte 이나,
일률적으로 32 bytes 길이로 생성한다.
-------------------------- CSV data sample (start) ---------------------------
userkey_12345678901_20140510141925000001,nickname_00_20140510141925000001
userkey_12345678901_20140510141925000002,nickname_00_20140510141925000002
userkey_12345678901_20140510141925000003,nickname_00_20140510141925000003
userkey_12345678901_20140510141925000004,nickname_00_20140510141925000004
userkey_12345678901_20140510141925000005,nickname_00_20140510141925000005
userkey_12345678901_20140510141925000006,nickname_00_20140510141925000006
userkey_12345678901_20140510141925000007,nickname_00_20140510141925000007
-------------------------- CSV data sample (end) ---------------------------
‘CSV Data Set Config’ 에 설정하는 값들은 다음과 같다.
Column Description
Filename 인증 키(auth_key)와 닉네임 데이터를 포함한 CSV 파일 경로
Variable Names CSV 데이터를 로딩한 후, 대입할 변수 명칭들
Recycle on EOF 파일 끝에 도달했을 때, 처음 데이터부터 다시 읽어 들이는지 여부
Stop thread on EOF 파일 끝에 도달해 더 이상 읽을 데이터가 없을 경우, 스레드(thread)를 중지하는지 여부
Sharing mode ‘All threads’로 설정한다.
27. 27
Thread Group
부하 테스트 시나리오에서는 ‘Thread Group’ 설정의 사용자 수 (Number of Threads), 램프 업 시간 (Ramp-up
Period), 반복 횟수 (Loop count)를 성능 테스트 목표에 맞도록 조정한다. (대상 서버 유형, 서버 성능, 테스트
목적에 따라 매번 다르게 설정한다.)
참고로 램프 업(Ramp-up)이란 공장 등에서 사용하는 산업 용어이며, 장비 설치 이후 대량 양산에 들어가기까지
생산 능력의 증가를 의미하는 말이다. 예를 들어, 사용자 수를 10 명으로 설정하고 램프 업 시간을 30 초로 설정한
경우, 30 초 구간 내에 사용자(스레드)가 순차적으로 시작하게 된다. 램프 업 시간을 사용자 수로 나눈 값이 각
사용자 간 시간 간격이 된다. (3 초 마다 한 명씩 시작 혹은 출발하게 되는 것이다.)
부하 테스트를 jMeter GUI 모드에서 실행할 경우에는 아래 그림과 같이 ‘Number of Threads’, “Ramp-up Period’,
‘Loop Count’ 값을 상수로 지정하면 된다.
반면에 부하 테스트를 non-GUI 모드에서 수행하거나, 원격 테스트를 실시할 경우에는 jMeter property 를 참조하게
하고, property 값들을 jMeter 실행 인자로 지정한다. (상수로 설정하게 되면, 부하 수치를 변경하고자 할 때 마다
Test Plan 을 수정한 후 실행해야 한다.
28. 28
Timer (Constant & Uniform Random)
사용자의 서비스 사용 패턴을 모방하기 위해서는 ‘실제’ 사용자가 요청하는 행위 사이에 시간 차가 존재한다는 것을
고려해야 한다. 즉, 사용자는 아주 짧은 간격으로 서버에 요청하지 않는다. (달리 말해서 순간적으로 대량의 요청을
전송하는 것은 기계만이 가능한 것이다.) jMeter 는 서비스 요청 간에 일정한 시간 차이를 발생할 수 있도록
타이머(timer)를 제공한다. 다양한 타이머 유형이 존재하나, 일반적으로 고정 시간 타이머(Constant Timer)와 균일
랜덤 타이머(Uniform Random Timer)를 사용하는 것으로 충분하다.
고정 시간 타이머 설정 예시는 아래와 같다. 타이머가 포함된 요청(request)를 수행하기 전에 0.3 초를 대기하는
설정이다.
29. 29
균일 랜덤 타이머(Uniform Random Timer) 예시는 아래와 같다. 타이머가 포함된 요청을 수행하기 전에 최소 3 초,
최대 5 초의 랜덤 시간을 대기하는 설정이다.
Listener (Report)
성능 테스트 시 적용하는 Listener 는 ‘Aggregate Graph’, ‘Response Time Over Time’, ‘Transactions Per Second’
등 3 가지 이다. Aggregate Graph 를 제외한 나머지 2 가지 Listener 는 확장 플러그인에 포함되어 있다. 만일,
별도의 집계 툴을 사용하고자 로그 데이터를 저장하려고 할 경우에는 개별 요청에 대한 로그를 파일로 남길 수
있는 ‘Sample Data Writer’를 고려하면 된다.
Aggregate Graph (or Aggregate Report)
집계 보고(혹은 집계 리포트)는 각기 다른 명칭의 요청에 대한 요약 행(row)들을 포함하는 테이블을 생성한다.
각각의 요청에 대한 응답 정보 합계와 요청 횟수, 최소, 최대, 평균, 오류 빈도, 처리량 근사값(approximate
throughput), 초당 Kilobyte 단위 처리량 등을 제공한다.
집계 보고에 포함되는 항목들에 대한 간단한 설명은 다음과 같다.
Column Description
Label 샘플 명칭 (API 혹은 URL 명칭)
#Samples 특정 샘플의 요청(실행) 횟수
Average 평균 응답 시간
Median 응답 중간 집합의 수행 시간, 50%의 샘플은 Median 보다 응답시간이 작으며, 나머지는 응답 시간이 더
길다.
90% line 90%의 샘플은 ’90 % line’ 보다 적은 시간 내에 실행된다. 나머지 10%는 보다 수행 시간이 길다.
Min 최소 응답 시간
Max 최대 응답 시간
Error % 오류 발생 비율
Throughput 초/분/시간 당 수행된 요청 수
Kb/sec 초당 Kilobytes 단위로 계산된 처리량
30. 30
집계 보고는 특정 시점의 부하 테스트 결과를 수치화된 형태로 기록하여, 주기적/반복적 부하 테스트 수행 시
이력을 통해 개선/변화 추이를 분석하고, 객관적 성능 평가 자료로 활용될 수 있다.
일반적인 활용 방식은 Benchmark Test 수행 전에 Median, Max 응답 시간의 목표 값을 설정하고, 집계 보고를 통해
목표 달성 여부를 판정하는 것이다. 목표에 도달하지 못했을 경우에는 하드웨어 확장, 데이터베이스 쿼리 튜닝,
어플리케이션 점검 등을 통해 튜닝을 수행한 목표에 도달할 때까지 성능 측정을 반복하는 것이다.
Response Time over Time
부하 테스트 수행 구간 내에서 각 요청의 평균 응답 시간을 그래프로 출력한다. 서버에 대한 부하를 긴 시간(long
term)를 발생시켰을 때, 서비스 응답 시간이 시간의 흐름에 따라 증가하는지 여부를 분석할 수 있다. 또는
점진적으로 사용자가 증가하는 상황에서 서버의 응답 성능 추이를 파악할 수 있다. BMT 실시 결과 Response
Time 이 안정적이지 않을 경우, 서버 자원의 유출 혹은 감소(memory leak, I/O wait, database overload, application
error 등), 각종 장애 유무 등에 대한 점검을 실시한다. Response Timer over Time 리포트를 이용해 시스템의
신뢰성 및 안정성을 보증한다.
31. 31
Transactions per Seconds
통상적으로 TPS 라는 약어로 알려져 있으며, 서비스(혹은 시스템)이 동시에 수용할 수 있는 사용자 수 혹은
수용량을 평가하는 보편적인 평가 지표이다. TPS 를 이용해 시스템의 최대 처리 가능 용량을 측정할 수는 있지만,
‘허용 가능한 최대치’이며, ‘적정 처리량’은 아니다. 적정 처리량은 하드웨어/네트워크/데이터베이스 자원 등에
여유가 있는지 여부를 함께 고려해 산정해야 한다.
32. 32
4. 기능 및 부하 테스트 수행
준비 사항
기능 및 부하 테스트를 수행하기 위해서는 다음과 같은 사전 준비가 필요하다.
jMeter 설치 : 로컬 PC 혹은 개발 장비에 jMeter 어플리케이션이 설치되어 있어야 한다.
jMeter Test Plan : 기능 혹은 부하 테스트 수행을 위해 jMeter 테스트 플랜 파일을 작성해야 한다.
(파일 확장자 : jmx)
CSV 데이터 파일 : 성능 및 부하 테스트를 수행하기 위해서는 CSV 데이터 파일이 준비되어 있어야 한다.
기능 테스트 수행 절차
jMeter 실행 Test Plan 실행 (기능) 실행 결과 검토
jMeter 실행
기능 테스트는 부하를 발생시키지 않으므로, Local PC 에서 jMeter 를 GUI 방식으로 실행한다. jMeter 실행 파일은
jMeter 설치 폴더 아래에 존재하는 bin 폴더 내의 ‘jmeter.bat’ 파일이다.
jMeter 를 실행한 후, ‘API_unit_test.jmx’ 파일을 로드(load)한다.
33. 33
Test Plan 실행 (기능)
테스트 플랜(Test Plan)을 로드한 후, control-R 단축 키를 누르거나 메뉴 바에서 녹색 화살표 버튼을 클릭해
테스트를 실행한다.
실행 결과 검토
‘Summary Report’, ‘View Results in Tree’, ‘View Result Table’을 선택한 후, 실행 결과를 검토한다. 정상적으로
응답하지 않은 기능들은 붉은색으로 표시되며, Request 및 Response data 등을 검토하여 장애 원인을 분석한다.
부하 테스트 수행 절차
CSV generator 실행 Test Plan 실행 (부하) jMeter GUI 모드 실행
CSV input
Data file
성능 리포트 작성
Stress Test
수행 결과 (jtl)
Performance
Graph / Report
34. 34
CSV generator 실행
명령줄(command line)에서 CVS 를 생성하는 방법은 다음과 같다.
java -jar RandomUserCsvGenerator_fat.jar
위와 같이 CSV Generator 를 실행하면, 동일 폴더 내에 ‘TestUsers.csv’ 파일이 생성된다.
(CSV generator 에 대한 상세한 설명은 ‘5. CSV 데이터 생성’ 절을 참조한다.)
Test Plan 실행
부하 테스트 시에는 jMeter 를 non-GUI 모드로 실행한다. non-GUI 모드로 실행하기 위한 배치 스크립트 예시는
다음과 같다.
배치 스크립트에 포함된 환경 변수(environment variables)들은 다음과 같다.
Variable Description
JMETER_HOME jMeter 프로그램 설치 경로 (실행 프로그램 경로)
TEST_PLAN jMeter test plan 파일 명칭 (입력 파일 경로)
RESULT_FILE jMter test 수행 결과 파일 명칭 (출력 파일 경로)
jMeter 실행 인자(parameter)에 대한 설명은 다음과 같다.
-n : jMeter 를 non-GUI 모드로 실행한다.
-t : jMeter test plan 입력 파일이름을 설정한다.
-l : jMeter 테스트 수행결과 출력 파일 이름을 설정한다.
-J : jMeter 속성(property)를 설정한다. name=value 형식으로 설정한다.
위 예시에서는 ‘loops’, ‘ramp_up’, ‘threads’ 변수를 선언하였으며, 3 가지 변수는 thread group 에서 참조한다.
rem jMeter run batch script for Windows
rem set jMeter installation directory
set JMETER_HOME=D:apache-jmeter-2.11
rem set jMeter "test plan" script file name
set TEST_PLAN= API_load_test__2_login_browse.jmx
rem set jMeter stress test result file name
set RESULT_FILE= Stress_Resuts.jtl
%JMETER_HOME%binjmeter -n -t %TEST_PLAN% -l %RESULT_FILE% -Jloops=1 -Jramp_up=30 -
Jthreads=30
35. 35
배치 실행 스크립트 파일 명칭이 ‘run_jmeter.bat’이라고 가정했을 때, 배치 스크립트를 실행하면 아래와 유사한
결과가 출력된다.
C:run>run_jmeter
C:run>rem set jMeter installation directory
C:run>set JMETER_HOME=D:apache-jmeter-2.11
C:run>rem set jMeter "test plan" script file name
C:run>set TEST_PLAN= API_load_test__2_login_browse.jmx
C:run>rem set jMeter stress test result file name
C:run>set RESULT_FILE=_Stress_Resuts.jtl
C:run>D: apache-jmeter-2.11binjmeter -n -t API_load_test__
2_login_browse.jmx -l Stress_Resuts.jtl -Jloops=1
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=64m; support
was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; sup
port was removed in 8.0
Creating summariser <summary>
Created the tree successfully using API_load_test__2_login_browse.jmx
Starting the test @ Mon May 12 15:04:10 KST 2014 (1399874650593)
Waiting for possible shutdown message on port 4445
summary + 94 in 19.1s = 4.9/s Avg: 223 Min: 134 Max: 587 Err: 19 (20.21%) Active: 20 Started: 20 Finished: 0
summary + 183 in 30.2s = 6.1/s Avg: 247 Min: 90 Max: 499 Err: 18 (9.84%) Active: 30 Started: 30 Finished: 0
summary = 277 in 49.1s = 5.6/s Avg: 239 Min: 90 Max: 587 Err: 37 (13.36%)
summary + 81 in 30.4s = 2.7/s Avg: 157 Min: 79 Max: 400 Err: 51 (62.96%) Active: 3 Started: 30 Finished: 27
36. 36
summary = 358 in 80s = 4.5/s Avg: 220 Min: 79 Max: 587 Err: 88 (24.58%)
summary + 2 in 1.1s = 1.8/s Avg: 173 Min: 164 Max: 183 Err:
2 (100.00%) Active: 0 Started: 30 Finished: 30
summary = 360 in 82.3s = 4.4/s Avg: 220 Min: 79 Max: 587 Err: 90 (25.00%)
Tidying up ... @ Mon May 12 15:05:33 KST 2014 (1399874733227)
... end of run
jMeter GUI 모드 실행
jMeter 를 non-GUI 모드로 실행했을 경우, 부하 테스트 실행 결과는 확장자가 ‘jtl’인 파일에 저장된다. 출력 결과는
jMeter 를 GUI 모드로 실행하고, 결과 파일을 로드(load)해 확인할 수 있다.
jMeter 를 실행한 후, 리포트를 생성할 listener 를 선택한다. Listener 내에서 ‘Write results to file / Read from file’
그룹의 ‘Filename’ 항목의 ‘Browse …’ 버튼을 클릭한다. 배치 수행 결과 jtl 파일을 선택하면 수행 결과를 chart /
report 형식으로 조회할 수 있다.
성능 리포트 작성
‘Reponse Times Over Time’, ‘Transactions per Seconds’ 등의 listener 에서 생성된 chart / graph 이미지를
클립보드로 복사하거나, CSV 파일 형식으로 출력(export)한 후 엑셀에서 편집하는 등의 방법으로 성능 리포트를
작성한다. Listener 의 그래프 화면을 마우스로 우클릭하면, 이미지를 클립보드로 복사하거나, CSV 로 출력하는
컨텍스트 메뉴(context menu)가 나타난다.