넥슨코리아 사내 발표자료로 왓 스튜디오에서 파이썬으로 《야생의 땅: 듀랑고》 서버를 비롯한 여러가지 도구를 만든 경험을 공유합니다.
- 게임서버와 각종 툴, 테스트/빌드/배포 시스템을 만들 때 사용한 재료
- 파이썬 코드 품질 개선, 디버깅, 프로파일링, 최적화
- 파이썬 오픈소스 생태계와 왓 스튜디오가 하는 오픈소스 활동
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...Amazon Web Services Korea
<쿠키런:킹덤> 게임 유저 수가 급증하면서 지금까지 겪어보지 못했던 대규모 인프라 환경을 운영하게 되었고, 그 과정에서 다양한 문제점들에 부딪히게 되었습니다. 이 세션에서는 AWS에서 Stateful 한 게임 서버를 어떻게 운영해야 하는지 아키텍처 관점에서 먼저 설명한 후, 수 백만 명의 사용자를 감당하기 위해 해결해야 했던 어려움에 대해 Scalability 관점에서 설명해드립니다.
PUBG: Battlegrounds 라이브 서비스 EKS 전환 사례 공유 [크래프톤 - 레벨 300] - 발표자: 김정헌, PUBG Dev...Amazon Web Services Korea
PUBG: Battlegrounds를 위한 게임 관련 인프라를 EKS 기반 환경으로 모두 전환한 경험에 대해 공유해 드릴 예정입니다. PUBG의 글로벌 서비스를 위한 인프라 구성에 대해 간단히 소개하고, 라이브 서비스 중인 인프라를 EC2 기반에서 EKS 기반으로 점진적으로 전환하면서 겪었던 문제들과 소중한 경험들을 사례를 통해 전달해드립니다.
Windows IOCP vs Linux EPOLL Performance ComparisonSeungmo Koo
1. The document compares the performance of IOCP and EPOLL for network I/O handling on Windows and Linux servers.
2. Testing showed that throughput was similar between IOCP and EPOLL, but IOCP had lower overall CPU usage without RSS/multi-queue enabled.
3. With RSS/multi-queue enabled on the NIC, CPU usage was nearly identical between IOCP and EPOLL.
배민찬(https://www.baeminchan.com) 서비스의 백엔드 시스템 중 일부가 지난 1년간 어떤 고민과 아이디어, 결과물을 만들어냈는지 공유하려고 합니다. 발표 중 언급되는 용어나 도구에 대해 일반적인 정의나 간단한 설명은 언급되나 자세히 다루지 않습니다. 사용된 도구들로 어떻게 이벤트 기반 분산 시스템을 만들었는지에 대한 이야기가 중심입니다.
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
Oracle SOA Suite Performance Tuning- UKOUG Application Server & Middleware SI...C2B2 Consulting
Matt Brasier, C2B2 Head of Consulting speaking at the UK Oracle User Group App Server & Middleware Special Interest Group Event on Wednesday, the 9th of October 2013.
Introducing SOA and Oracle SOA Suite 11g for Database ProfessionalsLucas Jellema
This session introduces SOA and the new Oracle SOA Suite 11g to the realm of database professionals from which it sometimes seems so far removed. What are the key SOA concepts and objectives? What is at the heart of Oracle SOA Suite 11g: composite applications, BPEL PM, and the mediator. The session shows how SOA services can be leveraged from the database, from triggers, PL/SQL units, or even SQL and how the database can publish events to the event delivery network. It covers how the SOA infrastructure can access the database, primarily using Oracle Database and Oracle Advanced Queueing adapter and how database developers can help in doing so efficiently. It ends with hints for applying SOA concepts to "normal" database development.
클라우드에서 인프라 구축 시 고려해야 할 사항들을 살펴보고, 네이버 클라우드 플랫폼을 활용하여 고가용성을 유지하는 방안에 대해 소개합니다. | Explore the considerations of building infrastructure in the cloud and introduce ways to maintain high availability by leveraging the Naver cloud platform.
급증하는 온라인 사용자 증가, 부하테스트가 필요하지 않으신가요?
요즘 인터넷 뉴스에는 홈페이지 접속자 폭증으로 인한 서버 다운, xx은행 모바일 앱 접속 에러, 인터넷 뱅킹 장애 등 온라인 시장과 모바일 시장이 급격하게 성장함에 따라 이에 따른 장애 소식이 끊이지 않고 전해지고 있습니다.
그렇다면, 우리는 이런 장애들을 어떻게 대비할 수 있을까요?
웹∙앱 부하테스트 (성능 진단) 및 컨설팅 안은 웹∙앱 부하테스트(성능 진단 테스트) 진행 과정과 이를 기반으로 어떻게 컨설팅을 진행하고 있는지 소개하고, 나아가 관련 장애들을 대비할 수 있는 방법에 대해 설명합니다.
(공유드리는 파일은 slideshare에 업로드되었던 웹∙앱 부하테스트 성능 진단 및 컨설팅 안을 업데이트한 최신 본입니다.)
웹∙앱 부하테스트 (성능 진단) 및 컨설팅 자료는 아래와 같이 구성되어있습니다.
• 웹∙앱 성능을 진단하고 문제에 대한 원인 분석 및 개선방향을 제시합니다.
• 컨설팅 안에는 여러 실 성능 진단을 예시로 들고 이에 대한 원인 분석 및 개선방향을 도
출한 내용이 포함되어 있습니다.
1. 앱 성능 진단
• 앱 진단 절차
• 앱 진단 상세 내용
2. 웹 서버 성능 진단
• 웹 진단 절차
• 웹 진단 방향
3. 부하 테스트
• 현 테스트 시나리오 분석
• 테스트 시나리오 보완 방법
• 부하 테스트 진행 방안
• 부하 테스트 전략
• 클라우드 기반 테스트 방안
모바일 성능 모니터링, 웹 서버 성능 진단 및 부하테스트 컨설팅에 관심이 있으신 분은 아래 연락처로 연락해주시면, 전문 컨설턴트가 안내해드리겠습니다.
hhjung@onycom.com l 02-6395-7722
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차 인용 시에도 가급적 본 문서가 참고핚
자료들에 대핚 링크를 삽입해 주시기를 요청 드릱니다.
• 본 문서는 상업적인 목적을 위해 작성된 것이 아닙니다.
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)
클라이언트 계층
클라이언트 계층 어플리케이션 계층 정보 계층
서버 계층
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를 기록하기 위해 로그
생성 기능을 변경(혹은 구현).
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 테스트를 수행하라.
– 목표치를 계획하고, 여러 단계에 걸쳐 순차적으로 부하를 늘리며 테스트하라.
• 성능 특정 테이블 및 그래프를 작성하라.
– 테스트 결과에 대핚 리포트를 작성하여, 향후 개선 및 확장을 위핚 자료로 홗용핚다.
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)
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) 등 다양핚 선택권이 있습니다.
• 결론
– 매뉴얼을 잘 읽어 보세요. 그리고 모니터링을 잘 하는 수밖에….
–
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