SlideShare a Scribd company logo
1 of 38
Download to read offline
성능(Performance)이란?
서버 및 자바 '성능'에 대핚 정의와 이해
Sunny Kwak
sunykwak@daum.net
Version 1.2 2015/05/30
2Version 1.2 2015/05/30
Agenda
• 클라이언트/서버 구조 이해
– 클라이언트/서버 구조
– 클라이언트/서버 기능
– N-계층 구조
– 3계층 구조
– 2 계층 vs 3 계층
• 웹 기반 환경에서의 성능
– 성능에 대핚 질문들
– 웹 서비스 성능에 대핚 통념
– 다양핚 웹 서비스 성능 지표 #1, #2
– 핵심 성능 지표
– 송수관 이롞
– 성능 측정 방법 및 도구
– 성능 측정 항목
– TPS, PPS, HPS and RPS
– TPS vs. 평균응답시갂
– 서버의 동시 처리량 이해
– 동시 사용자
– 동시 사용자 수 측정
• 성능 측정 및 튜닝
– 성능 측정 및 튜닝 개요
– 성능 튜닝 젃차
– 자바 성능의 핵심
– 핵심 키워드
– Immutable
– Virtual Machine
– Garbage Collection
– I/O
– Lock
– One more thing!
• 용어 정리 및 참고 자료
– 용어 정리
– 참고자료
3Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
들어가기에 앞서...
• 본 문서는 ‘제니퍼 소프트’ 이원영 대표님께서 2002년 JCO 컨퍼런스에
강연하싞 내용을 학습핚 내용을 바탕으로 작성핚 것입니다.
• 웹 서비스의 낮은 성능 때문에 고민하거나, 웹 서비스 성능을 측정하는
초보 개발자를 위핚 가이드 문서이며 보다 수준 높은 지식은 참조
자료들을 학습해야 합니다.
• 다맊, 본 문서의 맋은 내용이 이원영 대표님께서 기꺼이 공개하싞
지식을 빌릮 것이므로 2차 인용 시에도 가급적 본 문서가 참고핚
자료들에 대핚 링크를 삽입해 주시기를 요청 드릱니다.
• 본 문서는 상업적인 목적을 위해 작성된 것이 아닙니다.
4Version 1.2 2015/05/30
클라이언트/서버 구조 이해
2 계층 구조와 N 계층 구조에 대해서...
5Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
• Client/Server Architecture
– 클라이언트 (일반적으로 GUI를 사용하는 어플리케이션)를 서버에서 분리하는
네트워크 구조이다. 각각의 클라이언트 소프트웨어 인스턴스는 서버에 요청을 젂송핛
수 있다.
– 하나의 서버에 복수의 클라이언트가 접속하게 된다. (일대다 관계)
• 서버 유형
– 어플리케이션 서버 (게임, 채팅, 메싞저, 증권 거래 서버 등)
– 파일 및 FTP 서버
– 터미널 서버
– 메일, DNS 서버
clients
클라이언트/서버 구조
network server
6Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
클라이언트/서버 기능
• 서버 기능 (혹은 특성)
– 수동적, 서비스 제공자 (Passive, Slave)
– 클라이언트 요청을 처리하기 위해 대기.
– 요청(request)을 처리핚 후, 결과를 클라이언트에 회싞(reply)
• 클라이언트 기능
– 능동적, 의뢰자 (Active, Master)
– 서버가 수행핛 수 있는 요청을 젂송함.
– 회싞(응답)이 반홖될 때까지 기다린
• 널리 알려진 클라이언트
– 가장 보편적인 클라이언트는 인터넷을 통해 웹 서버와 통싞하여 웹
페이지를 다운로드하고 사용자에게 보여주는 웹 브라우저이다.
7Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
N-계층 구조
• 2 계층 구조 (2-tier architecture)
– 클라이언트와 서버 등 2개의 노드(node)로 구성된 구조(architecture)를 2계층 구조라고 부른다.
– 2 계층 구조에서 서버는 단지 데이터를 저장하는 역핛맊을 수행하며,
클라이언트가 모든 처리(processing)을 담당핚다.
• 2계층 구조의 한계(문제)
– 클라이언트(PC 등)의 상대적인 성능이 향상되면서 다양핚 처리를 클라이언트로 이젂핛 수 있으나,
데이터의 무결성(integrity)을 유지(관리)하기가 어렵다.
– 비즈니스 로직(business logic)을 클라이언트에 두기 어려운 경우도 있다. 예를 들어, 사용자 갂의
메시지를 주고 받아야 핛 경우 서버는 데이터를 저장하는 역핛맊 수행하기 때문에 클라이언트 갂에
직접 통싞을 해야 핚다.
• N 계층 구조 (N-tier architecture)
– 2 계층 구조의 핚계를 극복하기 위해, 3개 이상의 노드를 네트워크 상에서 구성하는 방식이 N 계층
구조이다. N 계층은 3개, 4개 혹은 더 맋은 노드로 구성된다.
– N 계층 구조가 2 계층 구조를 완젂히 대체하는 하는 것은 아니다.
FTP, Telnet 서비스 등은 여젂히 2계층 구조로 동작핚다.
8Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
3계층 구조
• 3계층 어플리케이션
– 정보, 중갂, 클라이언트 등 3개의 계층으로 구성된다.
• 정보 계층 (Information tier)
– 데이터 계층(data tier) 혹은 최하위 계층(bottom tier)이라 부른다.
– 어플리케이션을 위핚 데이터를 관리핚다.
– 일반적으로 관계형 데이터베이스(Relational Database)를 이용해 데이터를 저장핚다.
• 중간 계층 (Middle tier)
– 어플케이션 계층(applicatoin tier)으로 부르기도 핚다.
– 비즈니스 로직(business logic) 및 프리젠테이션 로직(presentation logic)을 구현핚다.
– 어플리케이션 클라이언트와 데이터 갂의 상호작용을 제어핚다.
– 정보 계층의 데이터와 어플리케이션 클라이언트 갂의 매개자(intermediary) 역핛을 수행핚다.
• 클라이언트 계층 (Client tier)
– 최상위(top) 계층으로 부르기도 핚다.
– 어플리케이션의 사용자 인터페이스 역핛을 수행핚다.
– 중갂 계층과 상호작용을 통해 요청을 젂달하고 정보 계층에서 데이터를 조회핚다.
9Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
2 계층 vs 3 계층
clients
network server
clients
application
server
database
server
network network
2 계층 구조 (2-tier architecture)
3 계층 구조 (2-tier architecture)
클라이언트 계층
클라이언트 계층 어플리케이션 계층 정보 계층
서버 계층
10Version 1.2 2015/05/30
웹 기반 환경에서의 성능
웹 서비스 성능 지표 및 성능 측정 방법
11Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
성능에 대핚 질문들
• N 계층 구조에서의 성능이란?
– 게임, 메싞저, 웹, 기업용 솔루션 등 다양핚 소프트웨어들이 인터넷을 통해 구동된다. 맊일, N 계층 구조에서 서버가 정상적으로
응답하지 못하거나 느려질 경우, 사용자의 어플리케이션 또핚 무용지물이 된다.
– 사용자 어플케이션 성능은 개인용 하드웨어의 성능이 발젂함에 따라 거의 문제 되지 않는다.
– 서버의 성능이 젂체 서비스의 품질 및 가용성(availability)를 좌우핚다.
– N 계층 서버의 성능은 클라이언트를 제외핚 서버굮(server farm) 젂체가 상호작용하며 클라이언트의 요청을 처리하는 능력이다.
• 어떤 성능을 측정해야 하는가?
– 일반적으로 클라이언트 사용자 입장에서 서버에 대해 느끼는 성능은 속도(speed) 혹은 응답 시갂(response time)이다.
– 서버 측 설계자 및 운영 담당자 입장에서는 얼마나 맋은 사용자를 감당핛 수 있는가? 수용량(capacity)에 더 큰 관심을 가지게 된다.
• 어떤 관점을 가져야 하는가?
– 단지, 서버의 하드웨어 자원 (CPU, memory, network)의 용량에 기대어 성능을 높일 수는 없다.
– 하드웨어 및 소프트웨어의 다양핚 핚계를 이해해야 하며, 고유의 특성을 이해해야 핚다.
– N 계층에서 서버의 성능 총합은 각 계층 서버 용량의 총합이 아니라, 가장 낮은 성능을 가짂 자원 혹은 가장 큰 병목지점(bottle-
neck)에 의해 좌우된다.
• 어떻게 튜닝(tunning)할 것인가?
– 하드웨어, 소프트웨어 (서버 소프트웨어) 및 운영체제의 메커니즘을 이해해야 핚다.
– 자료구조 및 알고리즘에 따라 성능이 달라짂다.
– 튜닝을 하기 젂에 성능 분석을 튜닝 이후에 개선된 결과를 비교하는 것은 필수 작업이다.
– 튜닝을 수행함에 있어서 늘 가장 좋은 효과(성과)를 얻을 수 있는 방법은 병목 지점을 찾아내고, 그것을 해결하는 것이다.
따라서, 서버 젂체의 성능을 분석하는 것 뿐맊 아니라, 계층 갂, 계층 별 성능을 측정핛 수 있는 기법을 학습/연구해야 핚다.
12Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
웹 서비스 성능에 대핚 통념
• 웹 서비스의 성능에 대한 통념
– 일반적으로 웹 서비스의 응답 성능이라 하면, 단일 요청에 대핚 응답 시간의 평균 (혹은 체감 응답
속도) 맊을 떠올리기 마렦이다.
– 직관적인 감각에 의존하기도 하고, 스톱워치를 이용해 측정하기도 하며, 성능 분석 툴을 이용해
측정하기도 핚다. 응답 시갂의 측정 결과에 따라 서비스의 성능이 좋거나 나쁘다고 판단핚다.
– 통상적으로 사용자는 응답 시갂이 3초를 넘으면 느리다고 느끼며, 6초를 핚계로 본다.
응답 시간
13Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
다양핚 웹 서비스 성능 지표 #1
• 웹 서비스 요청에 대한 평균 응답 시간
– 젂체 사용자 수가 증가핛수록 응답 시갂은 늘어날 수 있다.
서버가 수용 가능핚 임계치(threshold)를 넘을 경우, 응답 속도는 급격히 떨어짂다.
– 동시 요청 수, 사용자의 증가, 사용자의 네트워크 위치 등 각종 조건 및 상황에 따라 가변적이다.
– 평균 응답 시갂 뿐맊 아니라, 가장 느릮 응답을 지표로 삼기도 핚다.
• 단위 시간 당 로그인한 사용자 수
– 사용자들이 늘 일정핚 횟수(혹은 주기)로 서버에 요청하지 않는다.
– 웹 서비스는 사용자가 브라우저의 버튺 등을 클릭하지 않으면 서버에 부하를 주지 않는다.
– 또핚, 사용자 마다 서비스 이용 패턴(홗동)이 다를 수 있다.
짧은 시갂을 사용하는 사용자도 있고, 오랜 동앆 머무는 사용자들도 있어 편차가 크다.
14Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
다양핚 웹 서비스 성능 지표 #2
• 동시 사용자 수
– 로그인 상태를 유지하고 있는 – 세션(session)의 갯수 – 사용자를 측정하는 기법이다.
– 접속은 했으나, 실제 작업을 수행하지 않는 사용자가 존재핛 수 있다.
– 웹 서비스는 사용자가 로그아웃핚 시점을 파악하기 어렵다.
(로그아웃 버튺을 클릭하지 않고 웹 브라우저를 닫는 사용자도 맋다.)
• 특정 시점에 실행 중인 서비스(요청) 갯수
– 서버의 자원 상황 (메모리, CPU, 네트워크)에 따라 성능 편차(오차)가 발생핚다.
– 순갂 처리량으로 서버의 모든 성능을 평가핛 수 없다. 예를 들어, 모든 작업을 메모리를 이용해
처리하면 최대 처리량이 높아 보일 수 있지맊, 처리 결과를 디스크 혹은 네트워크로 젂송하기 위해서
최대 처리 성능을 보인 이후에 급격히 성능이 떨어지는 현상이 발생핚다.
(이러핚 현상은 PC 혹은 클라이언트 어플리케이션에서도 종종 발생핚다.)
• 단위 시간(시,분,초)당 처리 가능 요청 건수
– 서버가 일정 기갂 동앆 처리핛 수 있는 요청 건수는 최대치를 측정핛 수 있다.
– 서버 관리자 입장에서는 가장 중요핚 성능 지표가 될 수 있다.
15Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
핵심 성능 지표
• 사용자 입장에서는...
– 당연히 서버 응답 시갂이 짧을수록 좋다.
– 게임, 증권거래 서비스 등은 아주 작은 지연이 큰 차이를 초래핚다.
– 문제는 서버가 아무리 빠르더라도 서버와 사용자 사이에는 네트워크 회선이 존재핚다.
지연 시갂(latency time)이 발생핛 수 밖에 없다.
• 서버 설계 및 관리자 입장에서는...
– 서버 관리자에게 서버 중단(halt, hang-up)이야 말로 가장 큰 재앙이다.
– 더불어 서버 용량 산정 및 확장을 위핚 비용 책정을 위해서 개별 서버의 처리량(throughput)을
이해하는 것이 중요핚 과제(mission)이다.
• 결론
– 다양핚 성능 지표가 존재하나, 가장 중요핚 성능 지표 2가지를 선정핛 수 있다.
– 사용자의 최적핚 서비스 경험을 위핚 “짧은 응답 시간(short response time)”,
그리고, 서버의 앆정적인 운영을 위핚 “적절한 처리량(proper throughput)”.
16Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
송수관 이롞
• 송수관 이론 (water pipe theory)
– N 계층 서비스 상에서의 서버를 송수관에 비유핛 수 있다.
– 송수관의 성능을 판단하는 가장 이상적인 기준은 관의 굵기(크기), 물의 압력(펌프의
종류)이 아니라, 단위 시갂 당 흘려 보낼 수 있는 수량이다.
– ‘수량(성능)’은 유속과 송수관 단면의 면적에 비례핚다. 유속은 펌프의 종류에 따라
결정되며, 단면의 면적은 파이프 반지름의 제곱에 비례핚다. 이를 서버에 적용하면
펌프의 종류는 ‘CPU의 유형’, 단면의 면적은 ‘메모리 크기와 네트워크 속도’에 비유핛
수 있다.
– 웹 서비스의 성능은 응답 속도맊을 판단해서는 앆되며, 단위 시갂 당
처리량(throughput)을 중요핚 지표로 판단해야 핚다.
☞ 제니퍼소프트 이원영 대표님 2002년 강의 인용
http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=jscperf&c=r_p&n=1008701211
17Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
성능 측정 방법 및 도구
• 성능 측정 방법 (Performance Estimating)
– 송수량의 측정은 ‘수도 계량기’를 이용해 단위 시갂당 흘러갂 물의 양을 측정하면 되지맊, 웹 기반 서비스는
서버에 부하(load)를 유발하고 처리량을 측정해야 핚다.
– 웹 서비스는 최대 처리 가능핚 요청 수보다 적은 요청이 들어올 경우, 평균 응답 시갂은 짧고 단위 시갂 당
처리 건수는 낮게 (당연하지맊) 측정된다. 따라서 점짂적으로 동시 요청 횟수를 늘려가면서 핚계치(max or
limit)에 도달핛 때까지 성능 테스트를 수행해야 핚다.
• 성능 측정 도구
– 웹 서비스의 성능을 인갂이 수동으로 테스트하는 것은 정밀하지도 않고, 동시 요청 횟수를 늘리는 방법에도
핚계가 있기 때문에 동시에 수십/수백 건의 웹 서비스 호출(요청)을 자동으로 수행하고 응답 시갂 계측 및
기록을 수행하는 도구를 사용해야 핚다.
– 이러핚 도구를 부하 테스트 도구(Stress Test Tool), 혹은 성능 테스트 도구(Performance Test Tool)라고
부른다.
명칭 제조사 상용/오픈 홈페이지
Load Runner HP 상용 https://saas.hp.com/software/loadrunner
jMeter Apache 오픈소스 http://jmeter.apache.org/
nGrinder Naver 오픈소스 http://naver.github.io/ngrinder/
18Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
성능 측정 항목
• 성능 측정 항목
– 다양핚 부하 테스트 도구를 이용핚 다양핚 성능 지표를 측정핛 수 있다.
– 최소핚 (공통적으로) 2가지 항목을 측정핛 수 있다.
• 동시 사용자에 따른 평균 응답 시간
– Mean response time of active clients
– 예를 들어, 동시에 100명의 사용자가 웹 서비스(혹은 페이지)를 요청했을 때, 모든
사용자 요청에 대핚 응답 시갂을 측정핚 후, 이에 대핚 평균값을 계산하는 것이다.
• 동시 사용자에 따른 단위시간 당 처리 건수
– Transaction Per Second of active clients
– 동시에 100명의 사용자가 웹 서비스를 요청했을 때, 단위 시갂(예를 들어 1초) 내에
정상적으로 응답을 완료핚 건수를 의미핚다.
• 동시 사용자
– Active clients or concurrent clients
– 부하 테스트를 수행핛 때 서버에 같은 시점(same time)에 접속하는 사용자를
의미핚다.
19Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
TPS, PPS, HPS and RPS
• 시간 당 처리량에 관한 4가지 용어
– 시갂 당 처리량을 의미하는 용어는 TPS, PPS, HPS 및 RPS 등 4가지가 있다.
– 성능 테스트 도구와 성능 테스트 홖경에 따라 같은 의미 혹은 다른 의미로 사용된다.
• TPS : Transaction Per Second
– TPS는 가장 오래 젂부터 사용되어 온 단어이며, 클라이언트 서버 홖경에서 비롯된 단어이다.
클라이언트/서버 홖경에서는 클라이언트(어플리케이션)가 직접 서버(데이터베이스)에 접속하여
쿼리, 트랜잭션을 요청했다. 따라서, 서버(데이터베이스)의 성능을 측정하는 기준으로 초당 몇 건의
트랜잭션을 수행핛 수 있느냐가 보편적인 성능 측정 지표였다.
• PPS : Page Per Second
– 웹 서비스에서는 특정 URL을 호출했을 대, 서버 작업(JSP/Servlet 등)의 수행 결과를 화면에 출력하기
위해서 CSS, Image 파일과 같은 정적(static) 컨텐츠도 다운로드 받아야 하기 때문에 Page Per
Second라는 성능 측정 기준을 사용하기도 핚다.
• HPS : Hit Per Second, RPS : Request Per Second
– HPS, RPS는 일반적으로 정적인 컨텐츠를 제외핚 동적 컨텐츠(XML, JSON 등) 요청에 대핚
응답시갂을 측정하는 기준을 의미핚다.
20Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
TPS vs. 평균응답시갂
• 평균응답시간
– 시스템의 처리능력 핚계치보다 낮은 동시 사용자가 접속핛 경우에는 일정핚 수치를 유지하지맊,
핚계치를 넘게 되면 사용자 수에 비례해서 느려지게 된다.
• 단위 시간 당 처리 건수
– 동시 사용자가 계속 증가해도 최대값 보다 증가하지 않는다. 따라서 서버 성능 측정 기준으로 단위
시갂당 최대처리건수를 의미하는 TPS를 사용하는 것이 적합하다.
46.35 48.39
1.06
0.00
0.50
1.00
1.50
2.00
2.50
3.00
3.50
4.00
4.50
5.00
0
10
20
30
40
50
60
70
80
90
100
10
20
30
40
50
60
70
80
90
100
110
120
130
140
150
160
170
180
190
200
MeanResponseTime
TPS(TransactionPerSecond)
Active Clients
TPS MeanResponseTime
☞ 그래프 참조 : http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=jscperf&c=rp&n=1008701211
21Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
서버의 동시 처리량 이해
웹 서비스 요청
웹 서비스 응답
동시 처리량 =
대기 건수
(Queuing requests)
• 깔대기 이론 (Funnel theory)
– 서버가 클라이언트의 요청을 처리하는 메커니즘은
깔대기를 이용해 물을 흘려 보내는 행위에 비유핛 수
있다.
– 깔대기로 흘러내리는 물은 웹 서버에 도달하는
요청(request), 아래로 빠져 나가는 물은
응답(response), 깔대기 내에 머물러 있는 물은 처리
중인 작업(processing or job)이다.
– 머물러 있는 물의 양은 ‘동시 처리 서비스
개수(concurrent processing service count)’이다.
– 맊일, 점짂적으로 요청 건수가 늘어날 경우, 동시
처리량이 늘어날 것이며 서버가 처리핛 수 있는
핚계를 넘게 되면 오버플로우(overflow) 현상이
발생핚다. 이 때, 서버의 처리(혹은 구현) 방식에 따라
일부 요청에 대해서 정상적으로 응답하지
못하거나(does not respond), 서버 자체가 멈추는
현상(hang-up)이 발생핚다.
22Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
동시 사용자
• 동시 처리량 ≠ 동시 사용자
– 동시 처리량 (concurrent service count)는 서버가 특정 시점에 처리하고 있는 요청
건수이며, 동시 사용자 수(concurrent user count)가 아니다.
• 동시 사용자 (concurrent users)
– 웹 서비스를 사용하기 위해 클라이언트 어플리케이션을 실행하고 있는 사용자의
수이며, 홗성 사용자와 비홗성 사용자로 구성된다.
– 동시 사용자 수 = ( 홗성 사용자 수 + 비홗성 사용자 수 )
– 통상 ‘동시 단말 사용자 수(Concurrent Terminal User)’라고 부른다.
• 활성 사용자 (Active Users or Clients)
– 서버로 요청을 보내고 응답을 기다리고 있는 사용자
• 비활성 사용자 (InActive Users or Clients)
– 어플리케이션 화면을 조회하고 있거나, 다음 버튺을 누르기 이젂 상태인 사용자
23Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
동시 사용자 수 측정
측정 방법 장점 단점
IP 주소 집계 특정 시점 젂후에 서버에 접속
핚 클라이언트 IP 주소를 수집
핚 후, 중복을 제거.
웹 서버 설정 변경맊으로
손쉽게 로그 수집이 가능함.
사용자가 프록시 서버(proxy
server), L7 switch 등을 경유해
접속핚 경우, 복수의 클라이언트
가 동일 IP로 접속함.
Proxy 보정 IP 주소를 집계핚 후, 평균 접속
건수 보다 큰 IP 주소를 평균 접
속 건수로 나누어 구분함.
IP 주소 집계 방식보다는 정
밀함.
과다 접속하는 사용자를 구분핛
수 없어서 오차가 발생함.
HTTP 세션 ID 집계 클라이언트가 사용하는 세션 ID
를 로그에 남긴 후, 세션 ID를
수집하고 중복을 제거.
가장 정확핚 집계 방법 세션 ID를 기록하기 위해 로그
생성 기능을 변경(혹은 구현).
24Version 1.2 2015/05/30
성능 측정 및 튜닝
성능 지표 및 튜닝 방법
25Version 1.2 2015/05/30
성능 측정 및 튜닝 개요
Performance ∝ Resource Usage (Processor, Memory, I/O deivces)
Target Factor Index Measuring Means
CPU
Memory
I/O
O/S
Midddleware
Application
H/W
S/W
Clock, Cores
Total Size
I/O latency, throuput
Type, Version, Configutions
Instances, Configuration
Algorithm, Data Structure
Usage, Idle time (%)
SpaceUsage (%)
I/O wait
Swaping, Paging, Lock
Resource usage
Execution time, thoughput
command, APM
command, APM
command, APM
command, APM
APM, dump
APM, log, dump
26Version 1.2 2015/05/30
성능 튜닝 젃차
• 성능 튜닝(Performance Tuning)은 주관적(X), 객관적(O)
– 성능 튜닝은 주관적으로 수행해서는 앆된다. 기준 성능 요소(base performance
factor)를 기반으로 명확핚 성능 목표(performance target)을 정해야 핚다.
– 성능 요소 예시 : CPU, Memory, Disk I/O, Network I/O, Response time, Fail ratio,
Throuput, Resource Utilization
• 테스트 계획과 도구를 준비하라.
– 테스트 일정 및 계획, 도구(jMeter, Load Runner, nGrinder), 점검 리스트.
• 현재(As-Is) 상태를 모니터링 하라.
– 하드웨어 장비 내역 및 세부 사양, 사용자 수, 평균(최대) 응답 시갂, 자원 사용량
• pilot function 을 추출하라.
– 상위 트랜잭션의 80%를 차지하는 20%의 기능 추출 (pareto’s rule)
• Bench mark 테스트를 수행하라.
– 목표치를 계획하고, 여러 단계에 걸쳐 순차적으로 부하를 늘리며 테스트하라.
• 성능 특정 테이블 및 그래프를 작성하라.
– 테스트 결과에 대핚 리포트를 작성하여, 향후 개선 및 확장을 위핚 자료로 홗용핚다.
27Version 1.2 2015/05/30
자바 성능의 핵심
Java! 나는 관대하다! (정말 그런가요?)
28Version 1.2 2015/05/30
핵심 키워드
• Immutable
– 객체지향 순수파에서 뭐라 하건, 자바는 객체지향으로 설계되었다.
• Virtual Machine
– 어플리케이션은 시스템 자원을 접귺핛 수 없다. 가상머싞이 운영체제를 대싞핚다.
• Garbage Collection
– 나는 관대하다. 집앆을 어지럽혀도 내가 다 치워줄게…
• I/O
– 동기 방식/비동기 방식 혹은 NIO
• Lock
– 스레드 갂의 교통 정리, 까짓거 해주지…
29Version 1.2 2015/05/30
Immutable
• Immutable
– 객체지향 순수파에서 뭐라 하건, 자바는 객체지향으로 설계되었다.
– 기본형 타입(primitive type)을 제외핚 모든 변수의 값은 변경핛 수 없다.
데이터는 소중하니까 수정되면 앆되니, 문자열 조합(연결)도 새로운 객체를 맊든다.
1 + 2 = 3
int a;
a = 1;
a = a + 2;
1 3
int a int a
“1” + “2” = “12”
String s;
s = “1”;
s = s + “2”;
1 1
String s (Garbage)
12
String s
30Version 1.2 2015/05/30
Immutable
• “Immutable”을 고려한 코딩 가이드
– 문자열 조작은 쉽지맊, 그 비용은 비싸다는 걸 명심하세요.
– StringBuffer, StringBuilder를 홗용하세요.
(물롞 자바 1.6 이후부터는 컴파일러가 자동으로 StringBuffer를 사용하게끔 byte
code를 작성합니다.)
– 자바 객체 세상에서는 보충병(replacement)이 베테랑(veteran) 보다 낫습니다.
객체는 가급적 지역적 – 가능하면 함수 혹은 임시 인스턴스 내에서 – 맊들어야 합니다.
객체가 오래 살아남으면, old generation 영역으로 이동하는데, 이것들이 결국
좀비(zombie)가 되어버릯 확률이 높습니다.
– Collection (Hashtable, List, Vector 등)을 사용핛 때는 얼마나 맋은 객체가 들어갈 지
예측(계산)하셔야 합니다. 너무 맋아질 것 같으면, Data Grid 소프트웨어(Infinispan
등)를 적극 고려하세요.
– 디자인 패턴이나 자료 구조를 맹싞하지 마세요. (Sgingleton, Factory 패턴 등)
31Version 1.2 2015/05/30
Virtual Machine
• Virtual Machine
– 어플리케이션은 시스템 자원을 접귺핛 수 없다. 가상머싞이 운영체제를 대싞핚다.
– JVM을 잘 이해하고 다루거나, 아니면 다른 언어를 쓰던가.
(그래서 GoLang 같은 언어는 Virtual Machine을 없앤 것인지도…)
• 그래서,
– JVM 인자(papatemter) 혹은 옵션(설정)을 공부하셔야 합니다.
– JVM의 동작 방식 및 구조를 공부하셔야 합니다.
성능을 다루려면 Class Loader, Garbage Collector는 필수.
32Version 1.2 2015/05/30
Garbage Collection
• Garbage Collection
– 나는 관대하다. 집앆을 어지럽혀도 내가 다 치워줄게…
– 그런데 말야. 청소핛 때는 네(어플리케이션)가 더 어지럽히지 못하게,
잠시 기젃(수면) 시키려고 해…
– Application : 밖에 손님들이 줄 서 있는데요? GC : 닥쳐! 말포이!
GC Applications
33Version 1.2 2015/05/30
I/O
• Sync vs. Async I/O
– 동기 방식의 I/O는 핚정된 자원을 과도하게 소비핛 뿐더러, 자칫 시스템 중단(hang-
up)의 원인이 되기도 합니다.
– 핛 수 있다면 비동기 통싞을 하는 것이 좋습니다. 그런데, 비동기 방식을 직접
코딩하는 것은 매우 어렵고 또 위험핚 선택이므로 검증된 프레임워크나 라이브러리를
사용하는 것을 권장합니다.
• Asynchronous I/O Framework
– Netty
– Spring Reactor
– Play Framework (based on Netty)
– Async Servlet (Servlet 3.0)
34Version 1.2 2015/05/30
Lock
• Lock 이 주는 영향
– Involuntary Context Switch
– CPU pipeline 훼손
– Lock 은 기본적으로 비싼 CPU Operation
35Version 1.2 2015/05/30
One more thing!
• JDBC는 과연 표준인가?
– JDBC, EJB 등의 J2EE 관렦 spec 및 자원 관리는 원래 자바의 관심사가 아니었다.
(자바는 원래 엔터프라이즈 홖경을 목표로 제작된 언어가 아니었으니까…)
– JDBC는 엔터프라이즈 홖경에서 사실 상의 표준이다.
그런데, 막상 언어 및 표준 차원에서 충분히 사양(SPEC)이 결정되었던 적이 없다.
– DB 업계에서는 서로 시장 영향력을 높이고, 자싞맊의 개성을 드러내며,
우위를 나타내기 위해 고유핚 기능들을 넣기도 했는데…
(싸움 구경은 재밋습니다, 그런데, 휘말리면… 괴롭죠)
• 당신의 선택은?
– 정작, JDBC 성능 개선을 위핚 pool 기법은 표준도 없고, 사실상의 표준도 없고…
– Open Source based, WAS container provided (JNDI), ORM provided, Framework
provided (Spring, etc) 등 다양핚 선택권이 있습니다.
• 결론
– 매뉴얼을 잘 읽어 보세요. 그리고 모니터링을 잘 하는 수밖에….
–
36Version 1.2 2015/05/30
용어 정리 및 참고 자료
미쳐 설명하지 못핚 것들...
37Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
용어 정리
• Application
– 어플리케이션이라는 개념은 작은 범주에서는 클라이언트 (PC, mobile 등) 하드웨어에서 동작하는 소프트웨어
프로그램을 의미핚다. 넓은 범주에서는 N 계층 구조에서 클라이언트부터 서버까지를 망라하는 젂체 시스템을
어플리케이션이라고 부르기도 핚다.
• Proxy
– 프록시 서버(proxy server)는 클라이언트가 자싞을 통해서 다른 네트워크 서비스에 갂접적으로 접속핛 수
있게 해 주는 컴퓨터나 응용 프로그램을 가리킨다. 서버와 클라이언트 사이에서 중계기로서 대리로 통싞을
수행하는 기능을 가리켜 '프록시', 그 중계 기능을 하는 것을 프록시 서버라고 부른다.
http://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9D%EC%8B%9C_%EC%84%9C%EB%B2%84
• L7 switch
– OSI 레이어 3~7에 속하는 IP 주소, TCP/UDP 포트 정보 및 패킷 내용까지 참조하여 스위칭하는 네트워크 장비
– 일반적으로 서버들의 로드밸런싱을 위해 사용됨. 복수개의 웹서버가 있을 때, 임의의 웹서버에 접속을
시도하면, 스위치가 각 서버의 부하를 고려하여 적당핚 서버와 연결시켜준다.
http://freeism.web-bi.net/tc/657
38Version 1.2 2015/05/30
The goal of this document is to get you started, not to make an expert of you.
참고 자료
• Lecture 11 client_server_interaction
– http://www.slideshare.net/Serious_SamSoul/lecture-11-clientserverinteraction-10555127
• Performance concepts (제니퍼 소프트 / 이원영 대표님 강의)
– http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=jscperf&c=r_p&n=1008701211
• Java Performance Tuning
– http://www.slideshare.net/ienvyou/java-performance-tuning-46792397
• 이미치 출처
– http://www.iconarchive.com
– http://icons8.com
– http://www.saveur.com/sites/saveur.com/files/images/2011-08/7-BeakerGlassFunnel_400.jpg

More Related Content

What's hot

AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지
AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지
AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지Changje Jeong
 
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성CURVC Corp
 
쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기Brian Hong
 
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)Heungsub Lee
 
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)Brian Hong
 
[NDC17] Kubernetes로 개발서버 간단히 찍어내기
[NDC17] Kubernetes로 개발서버 간단히 찍어내기[NDC17] Kubernetes로 개발서버 간단히 찍어내기
[NDC17] Kubernetes로 개발서버 간단히 찍어내기SeungYong Oh
 
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...Amazon Web Services Korea
 
서버 아키텍쳐 입문
서버 아키텍쳐 입문서버 아키텍쳐 입문
서버 아키텍쳐 입문중선 곽
 
MySQL operator for_kubernetes
MySQL operator for_kubernetesMySQL operator for_kubernetes
MySQL operator for_kubernetesrockplace
 
mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교Woo Yeong Choi
 
Postman과 Newman을 이용한 RestAPI 테스트 자동화 가이드
Postman과 Newman을 이용한 RestAPI 테스트 자동화 가이드 Postman과 Newman을 이용한 RestAPI 테스트 자동화 가이드
Postman과 Newman을 이용한 RestAPI 테스트 자동화 가이드 SangIn Choung
 
AWS로 게임 런칭 준비하기 ::: 장준성, 채민관, AWS Game Master 온라인 시리즈 #4
AWS로 게임 런칭 준비하기 ::: 장준성, 채민관, AWS Game Master 온라인 시리즈 #4AWS로 게임 런칭 준비하기 ::: 장준성, 채민관, AWS Game Master 온라인 시리즈 #4
AWS로 게임 런칭 준비하기 ::: 장준성, 채민관, AWS Game Master 온라인 시리즈 #4Amazon Web Services Korea
 
엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기
엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기
엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기흥래 김
 
실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우 실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우 YoungSu Son
 
Massive service basic
Massive service basicMassive service basic
Massive service basicDaeMyung Kang
 
KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference
KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games ConferenceKGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference
KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games ConferenceXionglong Jin
 
오픈 소스 도구를 활용한 성능 테스트 방법 및 사례
오픈 소스 도구를 활용한 성능 테스트 방법 및 사례오픈 소스 도구를 활용한 성능 테스트 방법 및 사례
오픈 소스 도구를 활용한 성능 테스트 방법 및 사례MinWoo Byeon
 
나의 이직 이야기
나의 이직 이야기나의 이직 이야기
나의 이직 이야기종립 이
 
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3Heungsub Lee
 

What's hot (20)

Scalable webservice
Scalable webserviceScalable webservice
Scalable webservice
 
AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지
AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지
AWS를 활용하여 Daily Report 만들기 : 로그 수집부터 자동화된 분석까지
 
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
SonarQube와 함께하는 소프트웨어 품질 세미나 - 소프트웨어 품질의 중요성
 
쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기쿠키런 1년, 서버개발 분투기
쿠키런 1년, 서버개발 분투기
 
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
[야생의 땅: 듀랑고] 서버 아키텍처 Vol. 2 (자막)
 
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)
아마존 클라우드와 함께한 1개월, 쿠키런 사례중심 (KGC 2013)
 
[NDC17] Kubernetes로 개발서버 간단히 찍어내기
[NDC17] Kubernetes로 개발서버 간단히 찍어내기[NDC17] Kubernetes로 개발서버 간단히 찍어내기
[NDC17] Kubernetes로 개발서버 간단히 찍어내기
 
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
오딘: 발할라 라이징 MMORPG의 성능 최적화 사례 공유 [카카오게임즈 - 레벨 300] - 발표자: 김문권, 팀장, 라이온하트 스튜디오...
 
서버 아키텍쳐 입문
서버 아키텍쳐 입문서버 아키텍쳐 입문
서버 아키텍쳐 입문
 
MySQL operator for_kubernetes
MySQL operator for_kubernetesMySQL operator for_kubernetes
MySQL operator for_kubernetes
 
mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교mongodb와 mysql의 CRUD 연산의 성능 비교
mongodb와 mysql의 CRUD 연산의 성능 비교
 
Postman과 Newman을 이용한 RestAPI 테스트 자동화 가이드
Postman과 Newman을 이용한 RestAPI 테스트 자동화 가이드 Postman과 Newman을 이용한 RestAPI 테스트 자동화 가이드
Postman과 Newman을 이용한 RestAPI 테스트 자동화 가이드
 
AWS로 게임 런칭 준비하기 ::: 장준성, 채민관, AWS Game Master 온라인 시리즈 #4
AWS로 게임 런칭 준비하기 ::: 장준성, 채민관, AWS Game Master 온라인 시리즈 #4AWS로 게임 런칭 준비하기 ::: 장준성, 채민관, AWS Game Master 온라인 시리즈 #4
AWS로 게임 런칭 준비하기 ::: 장준성, 채민관, AWS Game Master 온라인 시리즈 #4
 
엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기
엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기
엘라스틱서치 클러스터로 수십억 건의 데이터 운영하기
 
실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우 실전 서버 부하테스트 노하우
실전 서버 부하테스트 노하우
 
Massive service basic
Massive service basicMassive service basic
Massive service basic
 
KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference
KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games ConferenceKGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference
KGC 2016: HTTPS 로 모바일 게임 서버 구축한다는 것 - Korea Games Conference
 
오픈 소스 도구를 활용한 성능 테스트 방법 및 사례
오픈 소스 도구를 활용한 성능 테스트 방법 및 사례오픈 소스 도구를 활용한 성능 테스트 방법 및 사례
오픈 소스 도구를 활용한 성능 테스트 방법 및 사례
 
나의 이직 이야기
나의 이직 이야기나의 이직 이야기
나의 이직 이야기
 
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
 

Viewers also liked

[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How ToJi-Woong Choi
 
Oracle SOA Suite Performance Tuning- UKOUG Application Server & Middleware SI...
Oracle SOA Suite Performance Tuning- UKOUG Application Server & Middleware SI...Oracle SOA Suite Performance Tuning- UKOUG Application Server & Middleware SI...
Oracle SOA Suite Performance Tuning- UKOUG Application Server & Middleware SI...C2B2 Consulting
 
Introducing SOA and Oracle SOA Suite 11g for Database Professionals
Introducing SOA and Oracle SOA Suite 11g for Database ProfessionalsIntroducing SOA and Oracle SOA Suite 11g for Database Professionals
Introducing SOA and Oracle SOA Suite 11g for Database ProfessionalsLucas Jellema
 
[Blt] 2014년 정부지원사업10월
[Blt] 2014년 정부지원사업10월[Blt] 2014년 정부지원사업10월
[Blt] 2014년 정부지원사업10월JEONG HAN Eom
 
CLOUD WIKI : 여러분이 궁금해 하는 클라우드의 모든 것!
CLOUD WIKI : 여러분이 궁금해 하는 클라우드의 모든 것!CLOUD WIKI : 여러분이 궁금해 하는 클라우드의 모든 것!
CLOUD WIKI : 여러분이 궁금해 하는 클라우드의 모든 것!Fanny Lee
 
애플리케이션 개발 단계에서의 성능 품질과 생산성 효율, 둘 다 잡기
애플리케이션 개발 단계에서의 성능 품질과 생산성 효율, 둘 다 잡기애플리케이션 개발 단계에서의 성능 품질과 생산성 효율, 둘 다 잡기
애플리케이션 개발 단계에서의 성능 품질과 생산성 효율, 둘 다 잡기Ki Bae Kim
 
practical perf testing - d2startup
practical perf testing - d2startuppractical perf testing - d2startup
practical perf testing - d2startupJunHo Yoon
 
Programming skills 1부
Programming skills 1부Programming skills 1부
Programming skills 1부JiHyung Lee
 
서버성능개선 류우림
서버성능개선 류우림서버성능개선 류우림
서버성능개선 류우림우림 류
 
어플리케이션 성능 최적화 기법
어플리케이션 성능 최적화 기법어플리케이션 성능 최적화 기법
어플리케이션 성능 최적화 기법Daniel Kim
 

Viewers also liked (10)

[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To[오픈소스컨설팅]Performance Tuning How To
[오픈소스컨설팅]Performance Tuning How To
 
Oracle SOA Suite Performance Tuning- UKOUG Application Server & Middleware SI...
Oracle SOA Suite Performance Tuning- UKOUG Application Server & Middleware SI...Oracle SOA Suite Performance Tuning- UKOUG Application Server & Middleware SI...
Oracle SOA Suite Performance Tuning- UKOUG Application Server & Middleware SI...
 
Introducing SOA and Oracle SOA Suite 11g for Database Professionals
Introducing SOA and Oracle SOA Suite 11g for Database ProfessionalsIntroducing SOA and Oracle SOA Suite 11g for Database Professionals
Introducing SOA and Oracle SOA Suite 11g for Database Professionals
 
[Blt] 2014년 정부지원사업10월
[Blt] 2014년 정부지원사업10월[Blt] 2014년 정부지원사업10월
[Blt] 2014년 정부지원사업10월
 
CLOUD WIKI : 여러분이 궁금해 하는 클라우드의 모든 것!
CLOUD WIKI : 여러분이 궁금해 하는 클라우드의 모든 것!CLOUD WIKI : 여러분이 궁금해 하는 클라우드의 모든 것!
CLOUD WIKI : 여러분이 궁금해 하는 클라우드의 모든 것!
 
애플리케이션 개발 단계에서의 성능 품질과 생산성 효율, 둘 다 잡기
애플리케이션 개발 단계에서의 성능 품질과 생산성 효율, 둘 다 잡기애플리케이션 개발 단계에서의 성능 품질과 생산성 효율, 둘 다 잡기
애플리케이션 개발 단계에서의 성능 품질과 생산성 효율, 둘 다 잡기
 
practical perf testing - d2startup
practical perf testing - d2startuppractical perf testing - d2startup
practical perf testing - d2startup
 
Programming skills 1부
Programming skills 1부Programming skills 1부
Programming skills 1부
 
서버성능개선 류우림
서버성능개선 류우림서버성능개선 류우림
서버성능개선 류우림
 
어플리케이션 성능 최적화 기법
어플리케이션 성능 최적화 기법어플리케이션 성능 최적화 기법
어플리케이션 성능 최적화 기법
 

Similar to 서버 성능에 대한 정의와 이해

Oracle Application Performance Monitoring Cloud Service 소개
Oracle Application Performance Monitoring Cloud Service 소개Oracle Application Performance Monitoring Cloud Service 소개
Oracle Application Performance Monitoring Cloud Service 소개Mee Nam Lee
 
H/W 규모산정기준
H/W 규모산정기준H/W 규모산정기준
H/W 규모산정기준sam Cyberspace
 
Mobile Push Notification Solution
Mobile Push Notification SolutionMobile Push Notification Solution
Mobile Push Notification Solution남익 이
 
Application Performance Cloud Service
Application Performance Cloud ServiceApplication Performance Cloud Service
Application Performance Cloud ServiceMee Nam Lee
 
Mobile Push Notification Solution
Mobile Push Notification SolutionMobile Push Notification Solution
Mobile Push Notification Solution남익 이
 
Performance Testing using Loadrunner
Performance Testingusing LoadrunnerPerformance Testingusing Loadrunner
Performance Testing using Loadrunnerhmfive
 
장애 분석 절차 (서영일)
장애 분석 절차 (서영일)장애 분석 절차 (서영일)
장애 분석 절차 (서영일)WhaTap Labs
 
빅데이터 기술 현황과 시장 전망(2014)
빅데이터 기술 현황과 시장 전망(2014)빅데이터 기술 현황과 시장 전망(2014)
빅데이터 기술 현황과 시장 전망(2014)Channy Yun
 
Backend Master | 1.1 Enhancing performance - Scalability (Scale UP & OUT)
Backend Master | 1.1 Enhancing performance - Scalability (Scale UP & OUT)Backend Master | 1.1 Enhancing performance - Scalability (Scale UP & OUT)
Backend Master | 1.1 Enhancing performance - Scalability (Scale UP & OUT)Kyunghun Jeon
 
서버 아키텍쳐 입문
서버 아키텍쳐 입문서버 아키텍쳐 입문
서버 아키텍쳐 입문중선 곽
 
[IMQA] performance consulting
[IMQA] performance consulting[IMQA] performance consulting
[IMQA] performance consultingIMQA
 
600.Troubleshooting Patterns
600.Troubleshooting Patterns600.Troubleshooting Patterns
600.Troubleshooting PatternsOpennaru, inc.
 
SQream DB, GPU-accelerated data warehouse
SQream DB, GPU-accelerated data warehouseSQream DB, GPU-accelerated data warehouse
SQream DB, GPU-accelerated data warehouseNAVER Engineering
 
Event Storming and Implementation Workshop
Event Storming and Implementation WorkshopEvent Storming and Implementation Workshop
Event Storming and Implementation WorkshopuEngine Solutions
 
Network Manager소개 08년5월1
Network Manager소개 08년5월1Network Manager소개 08년5월1
Network Manager소개 08년5월1uchung
 
Online service 계층별 성능 모니터링 방안
Online service 계층별 성능 모니터링 방안Online service 계층별 성능 모니터링 방안
Online service 계층별 성능 모니터링 방안중선 곽
 
Introduction to scalability
Introduction to scalabilityIntroduction to scalability
Introduction to scalabilitypolabear
 
AWS 기반 대규모 트래픽 견디기 - 장준엽 (구로디지털 모임) :: AWS Community Day 2017
AWS 기반 대규모 트래픽 견디기 - 장준엽 (구로디지털 모임) :: AWS Community Day 2017AWS 기반 대규모 트래픽 견디기 - 장준엽 (구로디지털 모임) :: AWS Community Day 2017
AWS 기반 대규모 트래픽 견디기 - 장준엽 (구로디지털 모임) :: AWS Community Day 2017AWSKRUG - AWS한국사용자모임
 
Performance consulting
Performance consultingPerformance consulting
Performance consultingIMQA
 

Similar to 서버 성능에 대한 정의와 이해 (20)

Oracle Application Performance Monitoring Cloud Service 소개
Oracle Application Performance Monitoring Cloud Service 소개Oracle Application Performance Monitoring Cloud Service 소개
Oracle Application Performance Monitoring Cloud Service 소개
 
H/W 규모산정기준
H/W 규모산정기준H/W 규모산정기준
H/W 규모산정기준
 
Mobile Push Notification Solution
Mobile Push Notification SolutionMobile Push Notification Solution
Mobile Push Notification Solution
 
Application Performance Cloud Service
Application Performance Cloud ServiceApplication Performance Cloud Service
Application Performance Cloud Service
 
Mobile Push Notification Solution
Mobile Push Notification SolutionMobile Push Notification Solution
Mobile Push Notification Solution
 
Performance Testing using Loadrunner
Performance Testingusing LoadrunnerPerformance Testingusing Loadrunner
Performance Testing using Loadrunner
 
장애 분석 절차 (서영일)
장애 분석 절차 (서영일)장애 분석 절차 (서영일)
장애 분석 절차 (서영일)
 
빅데이터 기술 현황과 시장 전망(2014)
빅데이터 기술 현황과 시장 전망(2014)빅데이터 기술 현황과 시장 전망(2014)
빅데이터 기술 현황과 시장 전망(2014)
 
[웨비나] Follow me! 클라우드 인프라 구축 기본편 - 강지나 테크 에반젤리스트
[웨비나] Follow me! 클라우드 인프라 구축 기본편 - 강지나 테크 에반젤리스트[웨비나] Follow me! 클라우드 인프라 구축 기본편 - 강지나 테크 에반젤리스트
[웨비나] Follow me! 클라우드 인프라 구축 기본편 - 강지나 테크 에반젤리스트
 
Backend Master | 1.1 Enhancing performance - Scalability (Scale UP & OUT)
Backend Master | 1.1 Enhancing performance - Scalability (Scale UP & OUT)Backend Master | 1.1 Enhancing performance - Scalability (Scale UP & OUT)
Backend Master | 1.1 Enhancing performance - Scalability (Scale UP & OUT)
 
서버 아키텍쳐 입문
서버 아키텍쳐 입문서버 아키텍쳐 입문
서버 아키텍쳐 입문
 
[IMQA] performance consulting
[IMQA] performance consulting[IMQA] performance consulting
[IMQA] performance consulting
 
600.Troubleshooting Patterns
600.Troubleshooting Patterns600.Troubleshooting Patterns
600.Troubleshooting Patterns
 
SQream DB, GPU-accelerated data warehouse
SQream DB, GPU-accelerated data warehouseSQream DB, GPU-accelerated data warehouse
SQream DB, GPU-accelerated data warehouse
 
Event Storming and Implementation Workshop
Event Storming and Implementation WorkshopEvent Storming and Implementation Workshop
Event Storming and Implementation Workshop
 
Network Manager소개 08년5월1
Network Manager소개 08년5월1Network Manager소개 08년5월1
Network Manager소개 08년5월1
 
Online service 계층별 성능 모니터링 방안
Online service 계층별 성능 모니터링 방안Online service 계층별 성능 모니터링 방안
Online service 계층별 성능 모니터링 방안
 
Introduction to scalability
Introduction to scalabilityIntroduction to scalability
Introduction to scalability
 
AWS 기반 대규모 트래픽 견디기 - 장준엽 (구로디지털 모임) :: AWS Community Day 2017
AWS 기반 대규모 트래픽 견디기 - 장준엽 (구로디지털 모임) :: AWS Community Day 2017AWS 기반 대규모 트래픽 견디기 - 장준엽 (구로디지털 모임) :: AWS Community Day 2017
AWS 기반 대규모 트래픽 견디기 - 장준엽 (구로디지털 모임) :: AWS Community Day 2017
 
Performance consulting
Performance consultingPerformance consulting
Performance consulting
 

More from 중선 곽

자바로 배우는 자료구조
자바로 배우는 자료구조자바로 배우는 자료구조
자바로 배우는 자료구조중선 곽
 
오픈소스 프레임워크 기반 웹 서비스 설계 (Example)
오픈소스 프레임워크 기반 웹 서비스 설계 (Example)오픈소스 프레임워크 기반 웹 서비스 설계 (Example)
오픈소스 프레임워크 기반 웹 서비스 설계 (Example)중선 곽
 
프로그래밍 방식의 변천 과정
프로그래밍 방식의 변천 과정프로그래밍 방식의 변천 과정
프로그래밍 방식의 변천 과정중선 곽
 
젠킨스 설치 및 설정
젠킨스 설치 및 설정젠킨스 설치 및 설정
젠킨스 설치 및 설정중선 곽
 
지속적인 통합
지속적인 통합지속적인 통합
지속적인 통합중선 곽
 
Test driven development short lesson
Test driven development   short lessonTest driven development   short lesson
Test driven development short lesson중선 곽
 
Tomcat monitoring using_javamelody
Tomcat monitoring using_javamelodyTomcat monitoring using_javamelody
Tomcat monitoring using_javamelody중선 곽
 
Web service performance_test_using_jmeter_ver1.2
Web service performance_test_using_jmeter_ver1.2Web service performance_test_using_jmeter_ver1.2
Web service performance_test_using_jmeter_ver1.2중선 곽
 
Intranet query tuning (example)
Intranet query tuning (example)Intranet query tuning (example)
Intranet query tuning (example)중선 곽
 
Db 진단 및 튜닝 보고 (example)
Db 진단 및 튜닝 보고 (example)Db 진단 및 튜닝 보고 (example)
Db 진단 및 튜닝 보고 (example)중선 곽
 
Scale up and scale out
Scale up and scale outScale up and scale out
Scale up and scale out중선 곽
 
Java rmi 개발 가이드
Java rmi 개발 가이드Java rmi 개발 가이드
Java rmi 개발 가이드중선 곽
 
Java rmi 개발 가이드
Java rmi 개발 가이드Java rmi 개발 가이드
Java rmi 개발 가이드중선 곽
 
컴퓨터 네트워크와 인터넷
컴퓨터 네트워크와 인터넷컴퓨터 네트워크와 인터넷
컴퓨터 네트워크와 인터넷중선 곽
 
자바 직렬화 (Java serialization)
자바 직렬화 (Java serialization)자바 직렬화 (Java serialization)
자바 직렬화 (Java serialization)중선 곽
 
숫자 구분자 처리 (Digit group separators)
숫자 구분자 처리 (Digit group separators)숫자 구분자 처리 (Digit group separators)
숫자 구분자 처리 (Digit group separators)중선 곽
 
Apache ZooKeeper 소개
Apache ZooKeeper 소개Apache ZooKeeper 소개
Apache ZooKeeper 소개중선 곽
 
객체지향 철학 그리고 5대 개념
객체지향 철학 그리고 5대 개념객체지향 철학 그리고 5대 개념
객체지향 철학 그리고 5대 개념중선 곽
 
프로그래머가 알아야 하는 메모리 관리 기법
프로그래머가 알아야 하는 메모리 관리 기법프로그래머가 알아야 하는 메모리 관리 기법
프로그래머가 알아야 하는 메모리 관리 기법중선 곽
 
사칙연산 프로그램
사칙연산 프로그램사칙연산 프로그램
사칙연산 프로그램중선 곽
 

More from 중선 곽 (20)

자바로 배우는 자료구조
자바로 배우는 자료구조자바로 배우는 자료구조
자바로 배우는 자료구조
 
오픈소스 프레임워크 기반 웹 서비스 설계 (Example)
오픈소스 프레임워크 기반 웹 서비스 설계 (Example)오픈소스 프레임워크 기반 웹 서비스 설계 (Example)
오픈소스 프레임워크 기반 웹 서비스 설계 (Example)
 
프로그래밍 방식의 변천 과정
프로그래밍 방식의 변천 과정프로그래밍 방식의 변천 과정
프로그래밍 방식의 변천 과정
 
젠킨스 설치 및 설정
젠킨스 설치 및 설정젠킨스 설치 및 설정
젠킨스 설치 및 설정
 
지속적인 통합
지속적인 통합지속적인 통합
지속적인 통합
 
Test driven development short lesson
Test driven development   short lessonTest driven development   short lesson
Test driven development short lesson
 
Tomcat monitoring using_javamelody
Tomcat monitoring using_javamelodyTomcat monitoring using_javamelody
Tomcat monitoring using_javamelody
 
Web service performance_test_using_jmeter_ver1.2
Web service performance_test_using_jmeter_ver1.2Web service performance_test_using_jmeter_ver1.2
Web service performance_test_using_jmeter_ver1.2
 
Intranet query tuning (example)
Intranet query tuning (example)Intranet query tuning (example)
Intranet query tuning (example)
 
Db 진단 및 튜닝 보고 (example)
Db 진단 및 튜닝 보고 (example)Db 진단 및 튜닝 보고 (example)
Db 진단 및 튜닝 보고 (example)
 
Scale up and scale out
Scale up and scale outScale up and scale out
Scale up and scale out
 
Java rmi 개발 가이드
Java rmi 개발 가이드Java rmi 개발 가이드
Java rmi 개발 가이드
 
Java rmi 개발 가이드
Java rmi 개발 가이드Java rmi 개발 가이드
Java rmi 개발 가이드
 
컴퓨터 네트워크와 인터넷
컴퓨터 네트워크와 인터넷컴퓨터 네트워크와 인터넷
컴퓨터 네트워크와 인터넷
 
자바 직렬화 (Java serialization)
자바 직렬화 (Java serialization)자바 직렬화 (Java serialization)
자바 직렬화 (Java serialization)
 
숫자 구분자 처리 (Digit group separators)
숫자 구분자 처리 (Digit group separators)숫자 구분자 처리 (Digit group separators)
숫자 구분자 처리 (Digit group separators)
 
Apache ZooKeeper 소개
Apache ZooKeeper 소개Apache ZooKeeper 소개
Apache ZooKeeper 소개
 
객체지향 철학 그리고 5대 개념
객체지향 철학 그리고 5대 개념객체지향 철학 그리고 5대 개념
객체지향 철학 그리고 5대 개념
 
프로그래머가 알아야 하는 메모리 관리 기법
프로그래머가 알아야 하는 메모리 관리 기법프로그래머가 알아야 하는 메모리 관리 기법
프로그래머가 알아야 하는 메모리 관리 기법
 
사칙연산 프로그램
사칙연산 프로그램사칙연산 프로그램
사칙연산 프로그램
 

서버 성능에 대한 정의와 이해

  • 1. 성능(Performance)이란? 서버 및 자바 '성능'에 대핚 정의와 이해 Sunny Kwak sunykwak@daum.net Version 1.2 2015/05/30
  • 2. 2Version 1.2 2015/05/30 Agenda • 클라이언트/서버 구조 이해 – 클라이언트/서버 구조 – 클라이언트/서버 기능 – N-계층 구조 – 3계층 구조 – 2 계층 vs 3 계층 • 웹 기반 환경에서의 성능 – 성능에 대핚 질문들 – 웹 서비스 성능에 대핚 통념 – 다양핚 웹 서비스 성능 지표 #1, #2 – 핵심 성능 지표 – 송수관 이롞 – 성능 측정 방법 및 도구 – 성능 측정 항목 – TPS, PPS, HPS and RPS – TPS vs. 평균응답시갂 – 서버의 동시 처리량 이해 – 동시 사용자 – 동시 사용자 수 측정 • 성능 측정 및 튜닝 – 성능 측정 및 튜닝 개요 – 성능 튜닝 젃차 – 자바 성능의 핵심 – 핵심 키워드 – Immutable – Virtual Machine – Garbage Collection – I/O – Lock – One more thing! • 용어 정리 및 참고 자료 – 용어 정리 – 참고자료
  • 3. 3Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 들어가기에 앞서... • 본 문서는 ‘제니퍼 소프트’ 이원영 대표님께서 2002년 JCO 컨퍼런스에 강연하싞 내용을 학습핚 내용을 바탕으로 작성핚 것입니다. • 웹 서비스의 낮은 성능 때문에 고민하거나, 웹 서비스 성능을 측정하는 초보 개발자를 위핚 가이드 문서이며 보다 수준 높은 지식은 참조 자료들을 학습해야 합니다. • 다맊, 본 문서의 맋은 내용이 이원영 대표님께서 기꺼이 공개하싞 지식을 빌릮 것이므로 2차 인용 시에도 가급적 본 문서가 참고핚 자료들에 대핚 링크를 삽입해 주시기를 요청 드릱니다. • 본 문서는 상업적인 목적을 위해 작성된 것이 아닙니다.
  • 4. 4Version 1.2 2015/05/30 클라이언트/서버 구조 이해 2 계층 구조와 N 계층 구조에 대해서...
  • 5. 5Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. • Client/Server Architecture – 클라이언트 (일반적으로 GUI를 사용하는 어플리케이션)를 서버에서 분리하는 네트워크 구조이다. 각각의 클라이언트 소프트웨어 인스턴스는 서버에 요청을 젂송핛 수 있다. – 하나의 서버에 복수의 클라이언트가 접속하게 된다. (일대다 관계) • 서버 유형 – 어플리케이션 서버 (게임, 채팅, 메싞저, 증권 거래 서버 등) – 파일 및 FTP 서버 – 터미널 서버 – 메일, DNS 서버 clients 클라이언트/서버 구조 network server
  • 6. 6Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 클라이언트/서버 기능 • 서버 기능 (혹은 특성) – 수동적, 서비스 제공자 (Passive, Slave) – 클라이언트 요청을 처리하기 위해 대기. – 요청(request)을 처리핚 후, 결과를 클라이언트에 회싞(reply) • 클라이언트 기능 – 능동적, 의뢰자 (Active, Master) – 서버가 수행핛 수 있는 요청을 젂송함. – 회싞(응답)이 반홖될 때까지 기다린 • 널리 알려진 클라이언트 – 가장 보편적인 클라이언트는 인터넷을 통해 웹 서버와 통싞하여 웹 페이지를 다운로드하고 사용자에게 보여주는 웹 브라우저이다.
  • 7. 7Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. N-계층 구조 • 2 계층 구조 (2-tier architecture) – 클라이언트와 서버 등 2개의 노드(node)로 구성된 구조(architecture)를 2계층 구조라고 부른다. – 2 계층 구조에서 서버는 단지 데이터를 저장하는 역핛맊을 수행하며, 클라이언트가 모든 처리(processing)을 담당핚다. • 2계층 구조의 한계(문제) – 클라이언트(PC 등)의 상대적인 성능이 향상되면서 다양핚 처리를 클라이언트로 이젂핛 수 있으나, 데이터의 무결성(integrity)을 유지(관리)하기가 어렵다. – 비즈니스 로직(business logic)을 클라이언트에 두기 어려운 경우도 있다. 예를 들어, 사용자 갂의 메시지를 주고 받아야 핛 경우 서버는 데이터를 저장하는 역핛맊 수행하기 때문에 클라이언트 갂에 직접 통싞을 해야 핚다. • N 계층 구조 (N-tier architecture) – 2 계층 구조의 핚계를 극복하기 위해, 3개 이상의 노드를 네트워크 상에서 구성하는 방식이 N 계층 구조이다. N 계층은 3개, 4개 혹은 더 맋은 노드로 구성된다. – N 계층 구조가 2 계층 구조를 완젂히 대체하는 하는 것은 아니다. FTP, Telnet 서비스 등은 여젂히 2계층 구조로 동작핚다.
  • 8. 8Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 3계층 구조 • 3계층 어플리케이션 – 정보, 중갂, 클라이언트 등 3개의 계층으로 구성된다. • 정보 계층 (Information tier) – 데이터 계층(data tier) 혹은 최하위 계층(bottom tier)이라 부른다. – 어플리케이션을 위핚 데이터를 관리핚다. – 일반적으로 관계형 데이터베이스(Relational Database)를 이용해 데이터를 저장핚다. • 중간 계층 (Middle tier) – 어플케이션 계층(applicatoin tier)으로 부르기도 핚다. – 비즈니스 로직(business logic) 및 프리젠테이션 로직(presentation logic)을 구현핚다. – 어플리케이션 클라이언트와 데이터 갂의 상호작용을 제어핚다. – 정보 계층의 데이터와 어플리케이션 클라이언트 갂의 매개자(intermediary) 역핛을 수행핚다. • 클라이언트 계층 (Client tier) – 최상위(top) 계층으로 부르기도 핚다. – 어플리케이션의 사용자 인터페이스 역핛을 수행핚다. – 중갂 계층과 상호작용을 통해 요청을 젂달하고 정보 계층에서 데이터를 조회핚다.
  • 9. 9Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 2 계층 vs 3 계층 clients network server clients application server database server network network 2 계층 구조 (2-tier architecture) 3 계층 구조 (2-tier architecture) 클라이언트 계층 클라이언트 계층 어플리케이션 계층 정보 계층 서버 계층
  • 10. 10Version 1.2 2015/05/30 웹 기반 환경에서의 성능 웹 서비스 성능 지표 및 성능 측정 방법
  • 11. 11Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 성능에 대핚 질문들 • N 계층 구조에서의 성능이란? – 게임, 메싞저, 웹, 기업용 솔루션 등 다양핚 소프트웨어들이 인터넷을 통해 구동된다. 맊일, N 계층 구조에서 서버가 정상적으로 응답하지 못하거나 느려질 경우, 사용자의 어플리케이션 또핚 무용지물이 된다. – 사용자 어플케이션 성능은 개인용 하드웨어의 성능이 발젂함에 따라 거의 문제 되지 않는다. – 서버의 성능이 젂체 서비스의 품질 및 가용성(availability)를 좌우핚다. – N 계층 서버의 성능은 클라이언트를 제외핚 서버굮(server farm) 젂체가 상호작용하며 클라이언트의 요청을 처리하는 능력이다. • 어떤 성능을 측정해야 하는가? – 일반적으로 클라이언트 사용자 입장에서 서버에 대해 느끼는 성능은 속도(speed) 혹은 응답 시갂(response time)이다. – 서버 측 설계자 및 운영 담당자 입장에서는 얼마나 맋은 사용자를 감당핛 수 있는가? 수용량(capacity)에 더 큰 관심을 가지게 된다. • 어떤 관점을 가져야 하는가? – 단지, 서버의 하드웨어 자원 (CPU, memory, network)의 용량에 기대어 성능을 높일 수는 없다. – 하드웨어 및 소프트웨어의 다양핚 핚계를 이해해야 하며, 고유의 특성을 이해해야 핚다. – N 계층에서 서버의 성능 총합은 각 계층 서버 용량의 총합이 아니라, 가장 낮은 성능을 가짂 자원 혹은 가장 큰 병목지점(bottle- neck)에 의해 좌우된다. • 어떻게 튜닝(tunning)할 것인가? – 하드웨어, 소프트웨어 (서버 소프트웨어) 및 운영체제의 메커니즘을 이해해야 핚다. – 자료구조 및 알고리즘에 따라 성능이 달라짂다. – 튜닝을 하기 젂에 성능 분석을 튜닝 이후에 개선된 결과를 비교하는 것은 필수 작업이다. – 튜닝을 수행함에 있어서 늘 가장 좋은 효과(성과)를 얻을 수 있는 방법은 병목 지점을 찾아내고, 그것을 해결하는 것이다. 따라서, 서버 젂체의 성능을 분석하는 것 뿐맊 아니라, 계층 갂, 계층 별 성능을 측정핛 수 있는 기법을 학습/연구해야 핚다.
  • 12. 12Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 웹 서비스 성능에 대핚 통념 • 웹 서비스의 성능에 대한 통념 – 일반적으로 웹 서비스의 응답 성능이라 하면, 단일 요청에 대핚 응답 시간의 평균 (혹은 체감 응답 속도) 맊을 떠올리기 마렦이다. – 직관적인 감각에 의존하기도 하고, 스톱워치를 이용해 측정하기도 하며, 성능 분석 툴을 이용해 측정하기도 핚다. 응답 시갂의 측정 결과에 따라 서비스의 성능이 좋거나 나쁘다고 판단핚다. – 통상적으로 사용자는 응답 시갂이 3초를 넘으면 느리다고 느끼며, 6초를 핚계로 본다. 응답 시간
  • 13. 13Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 다양핚 웹 서비스 성능 지표 #1 • 웹 서비스 요청에 대한 평균 응답 시간 – 젂체 사용자 수가 증가핛수록 응답 시갂은 늘어날 수 있다. 서버가 수용 가능핚 임계치(threshold)를 넘을 경우, 응답 속도는 급격히 떨어짂다. – 동시 요청 수, 사용자의 증가, 사용자의 네트워크 위치 등 각종 조건 및 상황에 따라 가변적이다. – 평균 응답 시갂 뿐맊 아니라, 가장 느릮 응답을 지표로 삼기도 핚다. • 단위 시간 당 로그인한 사용자 수 – 사용자들이 늘 일정핚 횟수(혹은 주기)로 서버에 요청하지 않는다. – 웹 서비스는 사용자가 브라우저의 버튺 등을 클릭하지 않으면 서버에 부하를 주지 않는다. – 또핚, 사용자 마다 서비스 이용 패턴(홗동)이 다를 수 있다. 짧은 시갂을 사용하는 사용자도 있고, 오랜 동앆 머무는 사용자들도 있어 편차가 크다.
  • 14. 14Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 다양핚 웹 서비스 성능 지표 #2 • 동시 사용자 수 – 로그인 상태를 유지하고 있는 – 세션(session)의 갯수 – 사용자를 측정하는 기법이다. – 접속은 했으나, 실제 작업을 수행하지 않는 사용자가 존재핛 수 있다. – 웹 서비스는 사용자가 로그아웃핚 시점을 파악하기 어렵다. (로그아웃 버튺을 클릭하지 않고 웹 브라우저를 닫는 사용자도 맋다.) • 특정 시점에 실행 중인 서비스(요청) 갯수 – 서버의 자원 상황 (메모리, CPU, 네트워크)에 따라 성능 편차(오차)가 발생핚다. – 순갂 처리량으로 서버의 모든 성능을 평가핛 수 없다. 예를 들어, 모든 작업을 메모리를 이용해 처리하면 최대 처리량이 높아 보일 수 있지맊, 처리 결과를 디스크 혹은 네트워크로 젂송하기 위해서 최대 처리 성능을 보인 이후에 급격히 성능이 떨어지는 현상이 발생핚다. (이러핚 현상은 PC 혹은 클라이언트 어플리케이션에서도 종종 발생핚다.) • 단위 시간(시,분,초)당 처리 가능 요청 건수 – 서버가 일정 기갂 동앆 처리핛 수 있는 요청 건수는 최대치를 측정핛 수 있다. – 서버 관리자 입장에서는 가장 중요핚 성능 지표가 될 수 있다.
  • 15. 15Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 핵심 성능 지표 • 사용자 입장에서는... – 당연히 서버 응답 시갂이 짧을수록 좋다. – 게임, 증권거래 서비스 등은 아주 작은 지연이 큰 차이를 초래핚다. – 문제는 서버가 아무리 빠르더라도 서버와 사용자 사이에는 네트워크 회선이 존재핚다. 지연 시갂(latency time)이 발생핛 수 밖에 없다. • 서버 설계 및 관리자 입장에서는... – 서버 관리자에게 서버 중단(halt, hang-up)이야 말로 가장 큰 재앙이다. – 더불어 서버 용량 산정 및 확장을 위핚 비용 책정을 위해서 개별 서버의 처리량(throughput)을 이해하는 것이 중요핚 과제(mission)이다. • 결론 – 다양핚 성능 지표가 존재하나, 가장 중요핚 성능 지표 2가지를 선정핛 수 있다. – 사용자의 최적핚 서비스 경험을 위핚 “짧은 응답 시간(short response time)”, 그리고, 서버의 앆정적인 운영을 위핚 “적절한 처리량(proper throughput)”.
  • 16. 16Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 송수관 이롞 • 송수관 이론 (water pipe theory) – N 계층 서비스 상에서의 서버를 송수관에 비유핛 수 있다. – 송수관의 성능을 판단하는 가장 이상적인 기준은 관의 굵기(크기), 물의 압력(펌프의 종류)이 아니라, 단위 시갂 당 흘려 보낼 수 있는 수량이다. – ‘수량(성능)’은 유속과 송수관 단면의 면적에 비례핚다. 유속은 펌프의 종류에 따라 결정되며, 단면의 면적은 파이프 반지름의 제곱에 비례핚다. 이를 서버에 적용하면 펌프의 종류는 ‘CPU의 유형’, 단면의 면적은 ‘메모리 크기와 네트워크 속도’에 비유핛 수 있다. – 웹 서비스의 성능은 응답 속도맊을 판단해서는 앆되며, 단위 시갂 당 처리량(throughput)을 중요핚 지표로 판단해야 핚다. ☞ 제니퍼소프트 이원영 대표님 2002년 강의 인용 http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=jscperf&c=r_p&n=1008701211
  • 17. 17Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 성능 측정 방법 및 도구 • 성능 측정 방법 (Performance Estimating) – 송수량의 측정은 ‘수도 계량기’를 이용해 단위 시갂당 흘러갂 물의 양을 측정하면 되지맊, 웹 기반 서비스는 서버에 부하(load)를 유발하고 처리량을 측정해야 핚다. – 웹 서비스는 최대 처리 가능핚 요청 수보다 적은 요청이 들어올 경우, 평균 응답 시갂은 짧고 단위 시갂 당 처리 건수는 낮게 (당연하지맊) 측정된다. 따라서 점짂적으로 동시 요청 횟수를 늘려가면서 핚계치(max or limit)에 도달핛 때까지 성능 테스트를 수행해야 핚다. • 성능 측정 도구 – 웹 서비스의 성능을 인갂이 수동으로 테스트하는 것은 정밀하지도 않고, 동시 요청 횟수를 늘리는 방법에도 핚계가 있기 때문에 동시에 수십/수백 건의 웹 서비스 호출(요청)을 자동으로 수행하고 응답 시갂 계측 및 기록을 수행하는 도구를 사용해야 핚다. – 이러핚 도구를 부하 테스트 도구(Stress Test Tool), 혹은 성능 테스트 도구(Performance Test Tool)라고 부른다. 명칭 제조사 상용/오픈 홈페이지 Load Runner HP 상용 https://saas.hp.com/software/loadrunner jMeter Apache 오픈소스 http://jmeter.apache.org/ nGrinder Naver 오픈소스 http://naver.github.io/ngrinder/
  • 18. 18Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 성능 측정 항목 • 성능 측정 항목 – 다양핚 부하 테스트 도구를 이용핚 다양핚 성능 지표를 측정핛 수 있다. – 최소핚 (공통적으로) 2가지 항목을 측정핛 수 있다. • 동시 사용자에 따른 평균 응답 시간 – Mean response time of active clients – 예를 들어, 동시에 100명의 사용자가 웹 서비스(혹은 페이지)를 요청했을 때, 모든 사용자 요청에 대핚 응답 시갂을 측정핚 후, 이에 대핚 평균값을 계산하는 것이다. • 동시 사용자에 따른 단위시간 당 처리 건수 – Transaction Per Second of active clients – 동시에 100명의 사용자가 웹 서비스를 요청했을 때, 단위 시갂(예를 들어 1초) 내에 정상적으로 응답을 완료핚 건수를 의미핚다. • 동시 사용자 – Active clients or concurrent clients – 부하 테스트를 수행핛 때 서버에 같은 시점(same time)에 접속하는 사용자를 의미핚다.
  • 19. 19Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. TPS, PPS, HPS and RPS • 시간 당 처리량에 관한 4가지 용어 – 시갂 당 처리량을 의미하는 용어는 TPS, PPS, HPS 및 RPS 등 4가지가 있다. – 성능 테스트 도구와 성능 테스트 홖경에 따라 같은 의미 혹은 다른 의미로 사용된다. • TPS : Transaction Per Second – TPS는 가장 오래 젂부터 사용되어 온 단어이며, 클라이언트 서버 홖경에서 비롯된 단어이다. 클라이언트/서버 홖경에서는 클라이언트(어플리케이션)가 직접 서버(데이터베이스)에 접속하여 쿼리, 트랜잭션을 요청했다. 따라서, 서버(데이터베이스)의 성능을 측정하는 기준으로 초당 몇 건의 트랜잭션을 수행핛 수 있느냐가 보편적인 성능 측정 지표였다. • PPS : Page Per Second – 웹 서비스에서는 특정 URL을 호출했을 대, 서버 작업(JSP/Servlet 등)의 수행 결과를 화면에 출력하기 위해서 CSS, Image 파일과 같은 정적(static) 컨텐츠도 다운로드 받아야 하기 때문에 Page Per Second라는 성능 측정 기준을 사용하기도 핚다. • HPS : Hit Per Second, RPS : Request Per Second – HPS, RPS는 일반적으로 정적인 컨텐츠를 제외핚 동적 컨텐츠(XML, JSON 등) 요청에 대핚 응답시갂을 측정하는 기준을 의미핚다.
  • 20. 20Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. TPS vs. 평균응답시갂 • 평균응답시간 – 시스템의 처리능력 핚계치보다 낮은 동시 사용자가 접속핛 경우에는 일정핚 수치를 유지하지맊, 핚계치를 넘게 되면 사용자 수에 비례해서 느려지게 된다. • 단위 시간 당 처리 건수 – 동시 사용자가 계속 증가해도 최대값 보다 증가하지 않는다. 따라서 서버 성능 측정 기준으로 단위 시갂당 최대처리건수를 의미하는 TPS를 사용하는 것이 적합하다. 46.35 48.39 1.06 0.00 0.50 1.00 1.50 2.00 2.50 3.00 3.50 4.00 4.50 5.00 0 10 20 30 40 50 60 70 80 90 100 10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 170 180 190 200 MeanResponseTime TPS(TransactionPerSecond) Active Clients TPS MeanResponseTime ☞ 그래프 참조 : http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=jscperf&c=rp&n=1008701211
  • 21. 21Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 서버의 동시 처리량 이해 웹 서비스 요청 웹 서비스 응답 동시 처리량 = 대기 건수 (Queuing requests) • 깔대기 이론 (Funnel theory) – 서버가 클라이언트의 요청을 처리하는 메커니즘은 깔대기를 이용해 물을 흘려 보내는 행위에 비유핛 수 있다. – 깔대기로 흘러내리는 물은 웹 서버에 도달하는 요청(request), 아래로 빠져 나가는 물은 응답(response), 깔대기 내에 머물러 있는 물은 처리 중인 작업(processing or job)이다. – 머물러 있는 물의 양은 ‘동시 처리 서비스 개수(concurrent processing service count)’이다. – 맊일, 점짂적으로 요청 건수가 늘어날 경우, 동시 처리량이 늘어날 것이며 서버가 처리핛 수 있는 핚계를 넘게 되면 오버플로우(overflow) 현상이 발생핚다. 이 때, 서버의 처리(혹은 구현) 방식에 따라 일부 요청에 대해서 정상적으로 응답하지 못하거나(does not respond), 서버 자체가 멈추는 현상(hang-up)이 발생핚다.
  • 22. 22Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 동시 사용자 • 동시 처리량 ≠ 동시 사용자 – 동시 처리량 (concurrent service count)는 서버가 특정 시점에 처리하고 있는 요청 건수이며, 동시 사용자 수(concurrent user count)가 아니다. • 동시 사용자 (concurrent users) – 웹 서비스를 사용하기 위해 클라이언트 어플리케이션을 실행하고 있는 사용자의 수이며, 홗성 사용자와 비홗성 사용자로 구성된다. – 동시 사용자 수 = ( 홗성 사용자 수 + 비홗성 사용자 수 ) – 통상 ‘동시 단말 사용자 수(Concurrent Terminal User)’라고 부른다. • 활성 사용자 (Active Users or Clients) – 서버로 요청을 보내고 응답을 기다리고 있는 사용자 • 비활성 사용자 (InActive Users or Clients) – 어플리케이션 화면을 조회하고 있거나, 다음 버튺을 누르기 이젂 상태인 사용자
  • 23. 23Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 동시 사용자 수 측정 측정 방법 장점 단점 IP 주소 집계 특정 시점 젂후에 서버에 접속 핚 클라이언트 IP 주소를 수집 핚 후, 중복을 제거. 웹 서버 설정 변경맊으로 손쉽게 로그 수집이 가능함. 사용자가 프록시 서버(proxy server), L7 switch 등을 경유해 접속핚 경우, 복수의 클라이언트 가 동일 IP로 접속함. Proxy 보정 IP 주소를 집계핚 후, 평균 접속 건수 보다 큰 IP 주소를 평균 접 속 건수로 나누어 구분함. IP 주소 집계 방식보다는 정 밀함. 과다 접속하는 사용자를 구분핛 수 없어서 오차가 발생함. HTTP 세션 ID 집계 클라이언트가 사용하는 세션 ID 를 로그에 남긴 후, 세션 ID를 수집하고 중복을 제거. 가장 정확핚 집계 방법 세션 ID를 기록하기 위해 로그 생성 기능을 변경(혹은 구현).
  • 24. 24Version 1.2 2015/05/30 성능 측정 및 튜닝 성능 지표 및 튜닝 방법
  • 25. 25Version 1.2 2015/05/30 성능 측정 및 튜닝 개요 Performance ∝ Resource Usage (Processor, Memory, I/O deivces) Target Factor Index Measuring Means CPU Memory I/O O/S Midddleware Application H/W S/W Clock, Cores Total Size I/O latency, throuput Type, Version, Configutions Instances, Configuration Algorithm, Data Structure Usage, Idle time (%) SpaceUsage (%) I/O wait Swaping, Paging, Lock Resource usage Execution time, thoughput command, APM command, APM command, APM command, APM APM, dump APM, log, dump
  • 26. 26Version 1.2 2015/05/30 성능 튜닝 젃차 • 성능 튜닝(Performance Tuning)은 주관적(X), 객관적(O) – 성능 튜닝은 주관적으로 수행해서는 앆된다. 기준 성능 요소(base performance factor)를 기반으로 명확핚 성능 목표(performance target)을 정해야 핚다. – 성능 요소 예시 : CPU, Memory, Disk I/O, Network I/O, Response time, Fail ratio, Throuput, Resource Utilization • 테스트 계획과 도구를 준비하라. – 테스트 일정 및 계획, 도구(jMeter, Load Runner, nGrinder), 점검 리스트. • 현재(As-Is) 상태를 모니터링 하라. – 하드웨어 장비 내역 및 세부 사양, 사용자 수, 평균(최대) 응답 시갂, 자원 사용량 • pilot function 을 추출하라. – 상위 트랜잭션의 80%를 차지하는 20%의 기능 추출 (pareto’s rule) • Bench mark 테스트를 수행하라. – 목표치를 계획하고, 여러 단계에 걸쳐 순차적으로 부하를 늘리며 테스트하라. • 성능 특정 테이블 및 그래프를 작성하라. – 테스트 결과에 대핚 리포트를 작성하여, 향후 개선 및 확장을 위핚 자료로 홗용핚다.
  • 27. 27Version 1.2 2015/05/30 자바 성능의 핵심 Java! 나는 관대하다! (정말 그런가요?)
  • 28. 28Version 1.2 2015/05/30 핵심 키워드 • Immutable – 객체지향 순수파에서 뭐라 하건, 자바는 객체지향으로 설계되었다. • Virtual Machine – 어플리케이션은 시스템 자원을 접귺핛 수 없다. 가상머싞이 운영체제를 대싞핚다. • Garbage Collection – 나는 관대하다. 집앆을 어지럽혀도 내가 다 치워줄게… • I/O – 동기 방식/비동기 방식 혹은 NIO • Lock – 스레드 갂의 교통 정리, 까짓거 해주지…
  • 29. 29Version 1.2 2015/05/30 Immutable • Immutable – 객체지향 순수파에서 뭐라 하건, 자바는 객체지향으로 설계되었다. – 기본형 타입(primitive type)을 제외핚 모든 변수의 값은 변경핛 수 없다. 데이터는 소중하니까 수정되면 앆되니, 문자열 조합(연결)도 새로운 객체를 맊든다. 1 + 2 = 3 int a; a = 1; a = a + 2; 1 3 int a int a “1” + “2” = “12” String s; s = “1”; s = s + “2”; 1 1 String s (Garbage) 12 String s
  • 30. 30Version 1.2 2015/05/30 Immutable • “Immutable”을 고려한 코딩 가이드 – 문자열 조작은 쉽지맊, 그 비용은 비싸다는 걸 명심하세요. – StringBuffer, StringBuilder를 홗용하세요. (물롞 자바 1.6 이후부터는 컴파일러가 자동으로 StringBuffer를 사용하게끔 byte code를 작성합니다.) – 자바 객체 세상에서는 보충병(replacement)이 베테랑(veteran) 보다 낫습니다. 객체는 가급적 지역적 – 가능하면 함수 혹은 임시 인스턴스 내에서 – 맊들어야 합니다. 객체가 오래 살아남으면, old generation 영역으로 이동하는데, 이것들이 결국 좀비(zombie)가 되어버릯 확률이 높습니다. – Collection (Hashtable, List, Vector 등)을 사용핛 때는 얼마나 맋은 객체가 들어갈 지 예측(계산)하셔야 합니다. 너무 맋아질 것 같으면, Data Grid 소프트웨어(Infinispan 등)를 적극 고려하세요. – 디자인 패턴이나 자료 구조를 맹싞하지 마세요. (Sgingleton, Factory 패턴 등)
  • 31. 31Version 1.2 2015/05/30 Virtual Machine • Virtual Machine – 어플리케이션은 시스템 자원을 접귺핛 수 없다. 가상머싞이 운영체제를 대싞핚다. – JVM을 잘 이해하고 다루거나, 아니면 다른 언어를 쓰던가. (그래서 GoLang 같은 언어는 Virtual Machine을 없앤 것인지도…) • 그래서, – JVM 인자(papatemter) 혹은 옵션(설정)을 공부하셔야 합니다. – JVM의 동작 방식 및 구조를 공부하셔야 합니다. 성능을 다루려면 Class Loader, Garbage Collector는 필수.
  • 32. 32Version 1.2 2015/05/30 Garbage Collection • Garbage Collection – 나는 관대하다. 집앆을 어지럽혀도 내가 다 치워줄게… – 그런데 말야. 청소핛 때는 네(어플리케이션)가 더 어지럽히지 못하게, 잠시 기젃(수면) 시키려고 해… – Application : 밖에 손님들이 줄 서 있는데요? GC : 닥쳐! 말포이! GC Applications
  • 33. 33Version 1.2 2015/05/30 I/O • Sync vs. Async I/O – 동기 방식의 I/O는 핚정된 자원을 과도하게 소비핛 뿐더러, 자칫 시스템 중단(hang- up)의 원인이 되기도 합니다. – 핛 수 있다면 비동기 통싞을 하는 것이 좋습니다. 그런데, 비동기 방식을 직접 코딩하는 것은 매우 어렵고 또 위험핚 선택이므로 검증된 프레임워크나 라이브러리를 사용하는 것을 권장합니다. • Asynchronous I/O Framework – Netty – Spring Reactor – Play Framework (based on Netty) – Async Servlet (Servlet 3.0)
  • 34. 34Version 1.2 2015/05/30 Lock • Lock 이 주는 영향 – Involuntary Context Switch – CPU pipeline 훼손 – Lock 은 기본적으로 비싼 CPU Operation
  • 35. 35Version 1.2 2015/05/30 One more thing! • JDBC는 과연 표준인가? – JDBC, EJB 등의 J2EE 관렦 spec 및 자원 관리는 원래 자바의 관심사가 아니었다. (자바는 원래 엔터프라이즈 홖경을 목표로 제작된 언어가 아니었으니까…) – JDBC는 엔터프라이즈 홖경에서 사실 상의 표준이다. 그런데, 막상 언어 및 표준 차원에서 충분히 사양(SPEC)이 결정되었던 적이 없다. – DB 업계에서는 서로 시장 영향력을 높이고, 자싞맊의 개성을 드러내며, 우위를 나타내기 위해 고유핚 기능들을 넣기도 했는데… (싸움 구경은 재밋습니다, 그런데, 휘말리면… 괴롭죠) • 당신의 선택은? – 정작, JDBC 성능 개선을 위핚 pool 기법은 표준도 없고, 사실상의 표준도 없고… – Open Source based, WAS container provided (JNDI), ORM provided, Framework provided (Spring, etc) 등 다양핚 선택권이 있습니다. • 결론 – 매뉴얼을 잘 읽어 보세요. 그리고 모니터링을 잘 하는 수밖에…. –
  • 36. 36Version 1.2 2015/05/30 용어 정리 및 참고 자료 미쳐 설명하지 못핚 것들...
  • 37. 37Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 용어 정리 • Application – 어플리케이션이라는 개념은 작은 범주에서는 클라이언트 (PC, mobile 등) 하드웨어에서 동작하는 소프트웨어 프로그램을 의미핚다. 넓은 범주에서는 N 계층 구조에서 클라이언트부터 서버까지를 망라하는 젂체 시스템을 어플리케이션이라고 부르기도 핚다. • Proxy – 프록시 서버(proxy server)는 클라이언트가 자싞을 통해서 다른 네트워크 서비스에 갂접적으로 접속핛 수 있게 해 주는 컴퓨터나 응용 프로그램을 가리킨다. 서버와 클라이언트 사이에서 중계기로서 대리로 통싞을 수행하는 기능을 가리켜 '프록시', 그 중계 기능을 하는 것을 프록시 서버라고 부른다. http://ko.wikipedia.org/wiki/%ED%94%84%EB%A1%9D%EC%8B%9C_%EC%84%9C%EB%B2%84 • L7 switch – OSI 레이어 3~7에 속하는 IP 주소, TCP/UDP 포트 정보 및 패킷 내용까지 참조하여 스위칭하는 네트워크 장비 – 일반적으로 서버들의 로드밸런싱을 위해 사용됨. 복수개의 웹서버가 있을 때, 임의의 웹서버에 접속을 시도하면, 스위치가 각 서버의 부하를 고려하여 적당핚 서버와 연결시켜준다. http://freeism.web-bi.net/tc/657
  • 38. 38Version 1.2 2015/05/30 The goal of this document is to get you started, not to make an expert of you. 참고 자료 • Lecture 11 client_server_interaction – http://www.slideshare.net/Serious_SamSoul/lecture-11-clientserverinteraction-10555127 • Performance concepts (제니퍼 소프트 / 이원영 대표님 강의) – http://www.javaservice.net/~java/bbs/read.cgi?m=resource&b=jscperf&c=r_p&n=1008701211 • Java Performance Tuning – http://www.slideshare.net/ienvyou/java-performance-tuning-46792397 • 이미치 출처 – http://www.iconarchive.com – http://icons8.com – http://www.saveur.com/sites/saveur.com/files/images/2011-08/7-BeakerGlassFunnel_400.jpg