Skip to content

Instantly share code, notes, and snippets.

@ihoneymon

ihoneymon/20190509-woowahan-tech-seminar-jvm.adoc

Last active May 19, 2023 07:00
Show Gist options
  • Star 11 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ihoneymon/bb992b3d57230a8e66749db1395538bd to your computer and use it in GitHub Desktop.
Save ihoneymon/bb992b3d57230a8e66749db1395538bd to your computer and use it in GitHub Desktop.
Download ZIP
2019/05/09 5월 우아한형제들 테크 세미나
Raw
20190509-woowahan-tech-seminar-jvm.adoc

20190509 우아한 테크 세미나: 자바, 성능, 모니터링

0. 소개

  • 성능테스트 전문가!

  • 개발자가 반드시 알아야 할 자바 성능 튜닝 이야기, 2015

  • 자바 개발자와 시스템 운영자를 위한 트러블 슈팅 이야기, 2011

    • 사내 교육에서 인기가 좋았다.

  • Scouter를 이용한 자바 트러블슈팅(집필중)

    • 상민님이 밀고 있는 중

    • 인터넷 검색만으로 알 수 없는 내용 담고 있음

  • 많은 집필을 하고 있음

1. 성능(Performance)

  • 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에서 저하가 발생할 수 있다.

TPS

  • 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

해봐서 아는데는 통하지 않는다.

"그 문제 그거 때문이야." 라고 하는 사람들 말은 믿지 마라!

모든 부분에서 영향을 받는다.

보틀넥 - Top3

  • Web Page/App

  • DB: 쿼리에 대한 검증 및 검수가 필요하다.

  • Network

정리

  • 성능 엔지니어링은 IT 분야에서 종합예술이다.

    • 메이븐을 사용하면 게이틀링 플러그인 설치가 가능하다.

    • 그렇다면 그레이들도 가능하겠구만. _)

2. 자바

자바 역사

자바 로드맵(Java RoadMap)

  • Java 11은 회사에서 사용해서는 안된다.

    • 로컬 개발 용도로 사용가능함

    • 상업적 목적으로 사용하는 경우에는 라이센스 비용발생

  • OpenJDK를 사용해라

Java 8

  • Lambda 표현식 추가

  • Stream 인터페이스 추가

  • 인터페이스 디폴트 메서드 추가

  • Date 관련 클래스 추가

Note

나이 든 개발자 머리를 아프게 하고, 코드의 가독성을 현저히 떨어뜨리는 람다와 스트림이 등장!

Java 9

  • 팁

    • Stream vs ParallelStream

      • Stream: forEach 처럼

        • Stream vs forEach 성능차이

      • ParellelStream

        • Fork-Join Pool

        • 장비의 CPU 개수만큼 스레드 생성

        • 10만개 까지는 차이가 없다.

    • Compact Strings

      • char[] → byte[]: 별거 아닌 것 같지만 강력함

    • G1 default GC

  • 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로 올리기만 해도 성능개선 효과를 볼 수 있다.

Java 10

Java 11

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)

  1. 스레드를 새롭게 생성할 수 없다며 OutOfMemory 가 발생한다.

Note

Once created, an HttpClient instance is immutable, thus automatically thread-safe, and you can send multiple requests with it.

  • Etc

    • Applets 삭제

    • Web Start 삭제

    • Java EE 와 CORBA 모듈 삭제

    • JavaFX 삭제

Java 12

OpenJDK

  • 다양한 종류가 출현했음

    • AdoptOpenJDK

    • Amazone Corretto

AdoptOpenJDK

  • OpenJDK 바이너리 오픈소스

  • CI/CD build Farm 의미

  • 2GB 메모리를 사용하고 있는 상황에서 4GB에 최적화된 G1을 사용할 수 있을까?

  • 답은 없다.

3. 모니터링

  • Agenda

    • APM

    • Scouter

Note

그래프!를 잘그려야 한다. * 1000 단위는 콤마(,)

APM

비교

특징 스카우터 핀포인트

강점

실시간 모니터링

전체 뷰, 분산 저장

단점

전체뷰, 분산저장(집킨(https://zipkin.io/)을 쓰면 일부 가능)

실시간 모니터링

Scouter

  • 그래프가 수려해지면서 별표가 늘어났다.

  • 보여주는 내용들에 대해서는 스카우터 사용시 반드시 넣어야 한다.

Agent plugin

  • httpservice.plug

  • service.plug

  • httpcall.plug

  • capture.plug: 이게 예술이야.

BCI 도구

  • BCI: Byte Code Instrumentation

  • ASM(http://asm.ow2.io/)

  • 추적은 HttpHeader를 이용한다.

FAQ

  • 핀포인트 와 스카우터는 병행해서 사용가능하다.

  • 페이스북 스카우터 페이지에 문의

  • 커밋을 자주 찍어서 스카우터 후드티를 받자!

4. Q&A

  • 스레드의 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 락 등을 발생시켜 보틀넥 발생(숙주 잡기)

  • 산불 패턴: 장애발생

    • 모를 때는 껐다켜라~

  • 갈대패턴: 락이 걸리는 경우

  • 크리스마스트리: 모니터링하지 않았던 시스템에 다양한 상황을 모니터링하는 용도로 사용

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment