DevSprout/optimizing-java

Chapter 01. 성능 최적화

Opened this issue · 6 comments

LOG-INFO commented
Chapter 01. 성능 최적화
MinJunKweon commented

모르는 용어

  • 메소드 디스패치(Method Dispatch)
    • 메시지에 대한 응답으로 어떤 메소드가 호출되어야하는지 결정하기 위해 사용하는 알고리즘
    • 각 언어들에 따라 구현방법이 드라마틱하게 다름
  • 세션 어피니티
    • Sticky Session과 동일어
    • 로드밸런서가 특정 서버에 클라이언트를 바인딩하는 기술

정리

  • JVM을 더 빨리 작동시키는 ‘마법의 스위치’는 없다.
  • 자바를 더 빨리 실행하게 하는 ‘팁, 트릭’은 없다.
    • 성능 최적화 기법은 상황에 따라 다르게 동작하므로 제대로 알고 써야함 (Trade-Off)
  • 꼭꼭 숨겨둔 ‘비밀 알고리즘’ 같은 건 없다.

성능 분류

  • 처리율(Throughput) : 시스템이 수행 가능한 작업 비율을 나타낸 지표
  • 지연(Latency) : 종단 시간. 요청을 보내고 처리되어 응답을 받기까지 걸리는 시간
  • 용량(Capacity) : 시스템이 보유한 작업 병렬성의 총량 (트랜잭션 개수)
  • 사용률(Utilization) : 워크로드를 처리할 때 리소스(CPU, MEM)를 사용하는 정도
  • 효율(Efficiency) : 처리율을 리소스 사용률로 나눈 값. 또는, 같은 처리율 대비 소요되는 비용(돈).
  • 확장성(Scalability) : 리소스 추가에 따른 처리율 변화
  • 저하(Degradation) : 부하 증가에 따라 생기는 처리량 저하 및 지연 상승

성능 측정을 잘해야하는 이유

  • 자주 실행되는 메소드가 아닌데 JIT 컴파일 대상이 된다면 성능이 안좋아질 수 있음
  • 워크로드 종류에 따라서도 달라짐
    • 은행 주문 체결은 오래걸리지만 주문 체결의 특정 서브시스템은 지연이 거의 없을 수 있음.
  • 성능 측정 결과를 해석하는 방법도 중요함
    • 갑자기 메모리 할당률이 확 떨어지는 경우를 해석한다거나
    • 초당 트랜잭션 수가 많아질수록 지연이 기하급수적으로 늘어난다거나 하는 경우

이상한 거

  • [그림 1-4] GC 사용량이 그래프 왜 톱니임? 내눈엔 톱니로 안보이는데?

참고

  • 👍1
LOG-INFO commented

나도 이상한 거 저거 말해볼라 했는데 ㅋㅋㅋㅋㅋㅋㅋㅋ

오 세션 어피니티 읽어보면서 스티키 세션인가? 나중에 찾아봐야지 하고 있었는데 맞군요 시간 절약 감사감사

MinJunKweon commented

세션 어피니티랑 스티키 세션이 동일하게 취급하는 글이 많길래 저렇게 썼는데, 어딘가 정확히 정의된 것은 없더라구요. 설명 봐도 똑같은 듯..

글고 톱니 내용은 딱 이해했어요
저게 점 그래프로 되어있는데, 선 그래프로 이해하고 보면 톱니에여

  • 👍1
LOG-INFO commented

정리

  • 모든 최적화 기법에는 함정과 트레이드오프가 도사리고 있으니 조심해야 함
    • 자바는 처음에 성능을 우선하는 언어는 아니었음. 오히려 성능을 희생해서 생산성을 높이는 것을 택함.
      • Hotspot VM이 나오면서부터 성능이 꽤 괜찮아짐
        • Hotspot VM?
          • 뒤에 나오긴 하지만 간단히 말하면, 오라클에서 개발한 JVM으로, 자주 사용되는(Hotspot) 구문을 프로파일링해서 컴파일하여 Native Code(Java Bytecode 아님)를 캐싱해두는 것
          • JIT Compiler 사용
          • Longview Technologies 라는 회사에서 개발했고, Oracle에서 유지보수
  • 측정값을 샘플링하면 특이점을 일으킨 가장 중요한 이벤트가 묻혀버릴 가능성이 큼
    • 드물게 Heavy API가 유입되어서 Pinpoint로 확인해보려 했는데 샘플링에 묻혀서 파악하지 못했던 경험이 있음
  • 하지만 샘플링을 안하거나 너무 자주하면 성능 결과 수치에 적잖은 영향을 끼침
    • Visualvm으로 Production 서버 샘플링 돌려놓고 깜빡하고 있다가 거의 OOME 낼 뻔했던 적 있음;;;;;

궁금한 점

  • 소프트웨어 산업의 가장 경이적인 성과는 하드웨어 산업에서 꾸준히 이루어낸 혁신을 끊임없이 무용지물로 만들고 있는 것이다
    • 요 말은 소프트웨어가 끊임없이 더 좋은 성능의 하드웨어를 요구한단 뜻이겠져??

몰랐던 용어 정리

  • 메서드 디스패치 (Method Dispatch): 어떤 메서드를 실행할지 결정하는 과정
    • static method dispatch: 컴파일 단계에서 결정됨
    • dynamic method dispatch: 런타임 단계에서 결정됨
      • ex) List<Integer> nums = new ArrayList<>(); nums.get(0);
  • 가상 디스패치
    • 자바의 가상 디스패치는 런타임 시점에 객체의 실제 타입을 파악하여 해당 타입에 정의된 메서드를 호출함
    • Q. dynamic method dispatch의 한 종류인건가?
  • 자동 인라인 (Automatic Managed Inlining)
    • 호출되는 메서드의 코드를 호출하는 코드에 삽입함으로써, 호출 오버헤드를 줄이고 성능을 향상시키는 기법
    • 자동 인라인화는 일반적으로 런타임 환경에서 수행되며, 일부 메서드는 자동으로 인라인화되지 않을 수 있음
  • 콜 사이트 (Call Site)
    • 메서드를 호출하는 코드에서는 호출될 메서드의 정보와 함께 해당 메서드를 가리키는 콜 사이트가 생성됨
    • 일반적으로 호출될 메서드의 주소 또는 참조를 저장하는 메모리 위치를 의미함
    • 콜 사이트에서 메서드 호출이 발생할 때, 해당 메서드의 실행 위치를 찾아 메서드 디스패치 과정을 수행
  • 서브시스템 (Managed Subsystem)
    • 메모리 관리, 스레드 관리, I/O 처리 등 다양한 부분에서 관리되는 서브시스템을 가지고 있음

추가

minkukjo commented

끄적 끄적

  • JVM을 더 빨리 구동시키는 마법은 없다! 자바를 더 빠르게 하는 팁, 트릭은 없다! 라는 것을 서두에 던져준 점이 좋았다. ( 물론 그런게 없다는건 알지만 혹시나 있나? 싶기도 했음 ㅎㅎ )
  • 자바는 블루 컬러 언어다. 박사 학위 논문 주제가 아니라 일을 하기 위해 만든 언어다! - By 제임스 고슬링
  • 성능 분석은 닭을 해부하는 것이 아닌, 통계치에 근거해 적절히 결과를 처리하는 활동이다!
  • 성능 엘보 : 그래프가 J 커브로 올라가는 그래프.
  • 메서드 디스패치 저도 처음 들어봐서 몰랐는데 감사합니다~ ㅋㅋ
  • 가상 디스패치라는 용어는 검색이 안되고 동적 디스패치만 나오는데 혹시 오역인가..?
  • 자동 인라인 기능을 자바에서는 컨트롤할 수 없었는데, 코틀린의 inline 함수는 이걸 명시적으로 할 수 있게 한 기능이라는 것을 이제야 알게 됐음.
  • 성능 측정은 주로 핀포인트로 하고 있는데, 샘플링이다보니 완벽하게는 안되지만 그래도 이정도면 뭐... 하는 느낌으로 사용 중 ㅋㅋ
HaeUlNam commented

정리

  • 자바 초창기에는 method dispatch 성능이 최악이었지만, 이후에 가상 디스패치 성능이 올라가고, 특히 최근에는 자동 인라이닝 덕분에 virtual dispatch 조차 대부분의 호출부에서 사라짐.
    • Method dispatch란? 실행할 메서드나 함수의 구현을 결정하는 매커니즘.
    • compile 시점에 결정하는 static dispatch, run time에 결정하는 dynamic dispatch가 존재.
    • Method dispatch 관련해서 찾다보니 double dispatch라는 내용을 알게 되었는데, 이는 mutiple 다형성이 필요한 케이스에서 사용되고 Java에서는 support하지 않기에 Visitor 패턴등을 통해 구현한다고 함(https://refactoring.guru/design-patterns/visitor-double-dispatch). 100퍼센트 이해한 게 아니라서 관련 유명 논문인 https://dl.acm.org/doi/10.1145/28697.28732 한번 살펴볼 예정..
      • Single polymorphism: 호출을 결정하기 위해 단 하나의 매개변수(Recevier)만 사용되는 유형
      • Mutiple polymorphism: 호출을 결정하기 위해 여러 매개변수(Recevier, method parameter)가 사용되는 유형
  • JVM Application의 성능 측정값은 정규 분포를 따르지 않는 경우가 많다?
    • 변수가 많은 복잡한 시스템일수록 롱테일 현상(파레토 법칙)을 따라가는 경우가 많다. JVM은 여러 요소들(GC, memory allocation, JIT, thread 등)등의 여러 복잡한 변수에 의해 결정되기에 Sampling 등으로 아웃라이어등을 무시하게 되면, 중요한 성능 포인트를 찾기 못할 수 있다.
    • Q. Pinpoint나 opentelemetry 같은 곳에서 파악할 수 있으면 가장 베스트이긴한데, Sampling에 걸리지 않는 상황에 대해 어떻게 분석하는지 궁금합니다. (e.g. 로그 분석? 에러 상황 재현?)
    • https://ko.wikipedia.org/wiki/%EA%B8%B4_%EA%BC%AC%EB%A6%AC
    • https://news.unist.ac.kr/kor/column_345/
  • JVM의 GC는 throughput, Latency, resource utilization(memory footprint)은 traingle 구조로서 서로를 영향을 줄 수 밖에 없다고 한다(https://blogs.oracle.com/javamagazine/post/java-garbage-collectors-evolution)