-
성능테스트 전문가!
-
개발자가 반드시 알아야 할 자바 성능 튜닝 이야기, 2015
-
자바 개발자와 시스템 운영자를 위한 트러블 슈팅 이야기, 2011
-
사내 교육에서 인기가 좋았다.
-
-
Scouter를 이용한 자바 트러블슈팅(집필중)
-
상민님이 밀고 있는 중
-
인터넷 검색만으로 알 수 없는 내용 담고 있음
-
-
많은 집필을 하고 있음
-
Agenda
-
왜 성능은 중요한가?
-
사용자
-
시간
-
TPS & 시간
-
보틀넥(Bottleneck)
-
-
성능개선
-
핀터레스트, 쿡에서 성능향상을 통해 검색 엔진 트래픽을 증가시키고 대기시간을 감축시킴
-
-
성능저하시
-
BBC, Doubleclick by google 3초 이상 응답시간을 가지는 사이트에서는 고객을 잃을 수 있다.
-
-
성능과 관련있는 항목들
-
시스템 관리자의 관점
-
등록 사용자
-
미등록 사용자: 가입유도
-
-
서버 관점(세션, 쿠키 등 처리)
-
로그인 사용자
-
미로그인 사용자
-
-
성능테스터의 관점
-
Concurrent User(동시 접속자): 서버 부하 유발 가능자(요청 후 결과를 확인하는 자)
-
ex) 코레일: 웹페이지 갱신시 순위를 하락시킴
-
서버에 부하 발생, 가능성이 높은 자
-
웹 페이지를 띄워놓은 자
-
앱을 띄워놓은 자
-
-
Active User(서버 부하 발생자): 서버 요청자
-
서버에 부하를 주고 있는 자
-
메뉴나 링크를 누르고 결과를 기다리고 있는자
-
성능테스트시 VUser와 동일
Note성능테스트에서 말하는 VUser는 '가상 사용자(Virtual User, Active)를 의미’한다.
-
-
-
성능테스트시 가장 중요한 것은 'Active User'!
-
사용자의 관점
-
응답시간(Response Time): 사용자에게는 이것이 전부
-
-
시스템의 관점
요청타임 → 응답시간 → 생각하는 시간 → 요청시간 → 응답시간
-
'사용자의 관점' 상세
요청시간(클라이언트 요청처리시간 + 네트워크 연결생성 처리시간 +요청 데이터 전송시간) → 응답시간(서버 요청처리시간 + 응답데이터 생성시간 + 네트워크 연결종료 처리시간 + 응답전송 및 클라이언트 처리시간)
Note
|
가장 성능에 영향을 많이 주는 구간은?
정답이 없다. CS 버전에서 웹 버전으로 변경하는 과정에서 요청데이터 처리에서 부하를 확인 * 상황에 따라 다르다. * 고객을 설득하랏! * 서버에서 가장 많은 시간을 허비된다고 하시는 분은!? 열악한 환경에서 일하고 있다. ** DB에서 저하가 발생할 수 있다. |
-
성능테스트 시
-
'서버에서 요청을 받고 처리하여 응답하는데 걸리는 시간’을 측정범위로 산정함
-
성능 테스트 도구(스크립트를 작성하여 테스트할 수 있어야 한다)
-
로드러너(https://www.microfocus.com/ko-kr/products/loadrunner-load-testing/overview, LoadRunner)
-
게틀링(https://gatling.io/, Gatling)
-
JMeter(https://jmeter.apache.org/)
-
Apache AB(https://httpd.apache.org/docs/2.2/ko/programs/ab.html, 아파치 웹서버 성능검사 도구)
-
-
-
TPS == Transaction Per Second == 초당 처리량(절대적 수치)
-
1초에 얼마나 많은 요청을 처리할 수 있나?
-
공식이 있다고~?
-
시스템에 대한 절대적 수치
-
TPS & Time
-
Scale out/up 을 통해서 증가시킬 수 있음 → 서버 증설
-
Time 은 Scale 로 불가능
-
시간은 튜닝으로 개선!
-
-
튜닝(Tuning)을 통해서 개선 가능
-
이것을 최적화 시켜라!
-
-
-
TPS & User
-
유저가 증가함에 따라 TPS 는 어느정도 증가한다.
-
유저 증가분에 따라 TPS도 점점 증가하다가 일정치(한계량)에 다다르면 없다.
-
-
성능 테스트 시에만 이쁜 그래프가 가능하다.
-
-
Time & User
-
유저가 증가함에 따라 시간은 일정속도를 유지하다가 점점 증가함
-
서버가 하고자 하는 업무에 최적화 되어 있는 것은 아니다.
-
보틀넥(Bottleneck)
-
장비내 문제
-
CPU
-
Memory
-
Disk
-
Network
-
-
애플리케이션 문제
-
Web
-
Was
-
-
저장소 문제
-
DBMS
-
Cache
-
-
설정의 문제
-
OS
-
WAS
-
DB
-
Note
|
해봐서 아는데는 통하지 않는다. "그 문제 그거 때문이야." 라고 하는 사람들 말은 믿지 마라! 모든 부분에서 영향을 받는다. |
-
혼란스러운 Java 버전의 진실(https://whatap.io/blog/12/)
-
Java 11은 회사에서 사용해서는 안된다.
-
로컬 개발 용도로 사용가능함
-
상업적 목적으로 사용하는 경우에는 라이센스 비용발생
-
-
OpenJDK를 사용해라
-
Lambda 표현식 추가
-
Stream 인터페이스 추가
-
인터페이스 디폴트 메서드 추가
-
Date 관련 클래스 추가
Note
|
나이 든 개발자 머리를 아프게 하고, 코드의 가독성을 현저히 떨어뜨리는 람다와 스트림이 등장! |
-
팁
-
Stream vs ParallelStream
-
Stream: forEach 처럼
-
Stream vs forEach 성능차이
-
-
ParellelStream
-
Fork-Join Pool
-
장비의 CPU 개수만큼 스레드 생성
-
10만개 까지는 차이가 없다.
-
-
-
Compact Strings
-
char[] → byte[]: 별거 아닌 것 같지만 강력함
-
-
G1 default GC
-
Getting Started with the G1 Garbage Collector(https://www.oracle.com/technetwork/tutorials/tutorials-1876574.html)
-
바둑판식으로 영역(기본 2MB)을 나눠서 처리함
-
-
-
Etc
-
java.util.concurrent.Flow 추가
-
Publisher, Subscriber 등장
-
-
Collections.of()`
-
List.of()
,Set.of()
,Map.of()
-
-
Unicode 8.0
-
-
JMH(https://openjdk.java.net/projects/code-tools/jmh/): OpenJDK JMH
-
Java 11로 올리기만 해도 성능개선 효과를 볼 수 있다.
-
var 등장: 타입 추론
-
Application Class Data Sharing(AppCDS, https://openjdk.java.net/jeps/310)
-
Oracle JDK 유료화
-
HttpClient 포함(https://openjdk.java.net/groups/net/httpclient/intro.html)
Client.java
var client = HttpClient.newBuilder() // (1)
.authenticator(Authenticator.getDefault())
.connectTimeout(Duration.ofSeconds(30))
.cookieHandler(CookieHandler.getDefault())
.executor(Executors.newFixedThreadPool(2))
.followRedirects(Redirect.NEVER)
.priority(1) //HTTP/2 priority
.proxy(ProxySelector.getDefault())
.sslContext(SSLContext.getDefault())
.version(Version.HTTP_2)
.sslParameters(new SSLParameters())
.build();
//
client = HttpClient.newHttpClient(); // (1)
-
스레드를 새롭게 생성할 수 없다며 OutOfMemory 가 발생한다.
Note
|
Once created, an |
-
Etc
-
Applets 삭제
-
Web Start 삭제
-
Java EE 와 CORBA 모듈 삭제
-
JavaFX 삭제
-
-
Switch expression(link:https://openjdk.java.net/jeps/325)
-
break
가 반환 값 처리
-
-
JMH 가 포함됨
-
Shenandoah(https://openjdk.java.net/projects/shenandoah/)
-
Wiki(https://wiki.openjdk.java.net/display/shenandoah/Main): 성능은 매우 뛰어나다
-
500ms 이하의 GC pause time
-
실험기능
-
-
-
Agenda
-
APM
-
Scouter
-
Note
|
그래프!를 잘그려야 한다.
* 1000 단위는 콤마( |
-
Commercial
-
Dynatrace(https://www.dynatrace.com/ko/)
-
서버에 에이전트만 실행하면 JVM 에이전트를 자동탐색하여 적용
-
-
New Relic(https://newrelic.com/)
-
AppDynamics(https://www.appdynamics.com/)
-
이상징후를 보이는 상황에 대해서 지능적으로 처리한다?
-
-
WhaTap(https://whatap.io/apm-java/)
-
-
OpenSource
-
PinPoint(https://github.com/naver/pinpoint)
-
성능저하가 없다. 라는 자신감! ㅋㅋ
-
특징 | 스카우터 | 핀포인트 |
---|---|---|
강점 |
실시간 모니터링 |
전체 뷰, 분산 저장 |
단점 |
전체뷰, 분산저장(집킨(https://zipkin.io/)을 쓰면 일부 가능) |
실시간 모니터링 |
-
그래프가 수려해지면서 별표가 늘어났다.
-
보여주는 내용들에 대해서는 스카우터 사용시 반드시 넣어야 한다.
-
BCI: Byte Code Instrumentation
-
ASM(http://asm.ow2.io/)
-
추적은 HttpHeader를 이용한다.
-
스레드의 Daemon 여부를 변경하면 된다.
-
애플리케이션이 왜 메모리를 많이 차지하고 있는지에 대해서 분석하고 튜닝을 한 후에 GC 튜닝을 해라.
-
Thread, DB Connection Pool 등의 설정 최적화
-
로그를 줄이는 것도 최적화
-
애플리케이션의 프로파일링을 통해 분석하고 튜닝해야 한다.
-
-
자바는 JIT 컴파일러가 실행되고 워밍없이 되어야 최적화된 후 성능이 빨라진다.
-
성능 개선의 기준점
-
누가 쓰는가?
-
얼마나 많이 쓰는가?
-
상위 5%의 URL을 분석해본다.
-
-
얼마나 느린가?
-
엄청나게 상대적이지만, 서비스의 상황에 따라서 0.5초 이상, 1초 2초 기준 이상으로 차이를 느끼기 어렵다.
-
-
기준을 어디에 잡느냐에 따라 다르다.
-
CPU 사용량, DB 호출 횟수가 많거나, DB 쿼리 실행시간이 길거나
-
-
-
APM 사용은 필수다.
-
없으면 안개속을 걷는 상황처럼 매우 불안할 수 밖에 없다.
-
모를 때는 상용APM을 설치해서 사용하는 것 추천
-
-
JVM이 죽는 이유는 여러가지
-
아무 이유없이 죽었다면 누군가가
kill -9
로 죽였을 수 있다. -
kill -3
thread dump 뜨기 -
jvm 이 비명횡사하면 로그를 남기고 죽는다.
-
-
APM 을 사용하면서 성능저하가 발생하지 않는다면 사기!
-
개발 서버 등에서 일정기간 운영하면서 확인하고 점증적으로 운영에 적용진행
-
적용/미적용 서버 성능 확인
-
-
JDK 분석하는 좋은 방법
-
JDK 소스를 봐라
-
JDK, Apache, Spring 코드를 봐라.
-
-
타임아웃이 발생하며 파도형이 발생하면 병목구간이 되는 요소를 찾아야 한다.
-
선형 그래프, 스토리지 타임아웃: 요청시도하다가 커넥션 타임아웃이 발생하면서 끝나는 경우
-
서버마다 타임아웃이 서로 다른경우
-
GC되는 경우는 비어있다가 쫙 올라간다.
-
-
운석낙하 패턴: 특정 요청이 DB 락 등을 발생시켜 보틀넥 발생(숙주 잡기)
-
산불 패턴: 장애발생
-
모를 때는 껐다켜라~
-
-
갈대패턴: 락이 걸리는 경우
-
크리스마스트리: 모니터링하지 않았던 시스템에 다양한 상황을 모니터링하는 용도로 사용
-
Dynatrace(https://www.dynatrace.com/ko/)
-
New Relic(https://newrelic.com/)
-
AppDynamics(https://www.appdynamics.com/)
-
WhaTap(https://whatap.io/apm-java/)
-
PinPoint(https://github.com/naver/pinpoint)
-
로드러너(https://www.microfocus.com/ko-kr/products/loadrunner-load-testing/overview, LoadRunner)
-
게틀링(https://gatling.io/, Gatling)
-
JMeter(https://jmeter.apache.org/)
-
Apache AB(https://httpd.apache.org/docs/2.2/ko/programs/ab.html, 아파치 웹서버 성능검사 도구)