0306 ~ 0319

0309 - JIT(Just-In Time compiler) 컴파일러란?

자바는 코드를 실행하기 위해서 바이트코드로 컴파일하는 과정과 바이트코드를 인터프리트하는 과정을 거쳐야하기 때문에 컴파일 과정만 필요한 다른 프로그래밍 언어보다 느리다. 거기에 더하여 인터프리터는 컴파일러보다 느리기 때문에 성능 문제가 발생할 수 밖에 없다.

인터프리터 방식의 단점을 보완하기 위해 도입됐다. JIT 컴파일러는 실행 시점에 인터프리터 방식으로 기계어 코드를 생성할 때 자주 사용되는 메소드의 경우 컴파일하고 기계어를 캐싱한다. 그리고 해당 메소드가 여러 번 호출할 때 매번 해석하는 것을 방지한다.

[ JIT 컴파일러 동작 방식 ]

JIT 컴파일러는 실행 시점에서는 인터프리터와 같이 기계어 코드를 생성하면서 해당 코드가 컴파일 대상이 되면 컴파일하고 그 코드를 캐싱한다. JIT 컴파일은 코드가 실행되는 과정에 실시간으로 일어나며, 전체 코드의 필요한 부분만 변환한다. 기계어로 변환된 코드는 캐시에 저장되기 때문에 재사용 시 컴파일을 다시 할 필요가 없다.

• JIT 컴파일러가 컴파일하는 조건은 얼마나 자주 코드가 실행됐는가 이다. 일정한 횟수만큼 실행되고 나면 컴파일 임계치에 도달하고 컴파일러는 컴파일하기에 충분한 정보가 쌓였다고 생각한다.
• 임계치는 메서드가 호출된 횟수, 메서드의 루프를 빠져나오기까지 돈 횟수 두 개를 기반으로 한다. 이 두 수의 합계를 확인하고 메서드가 컴파일될 자격이 있는지 여부를 결정한다. 자격이 있다면 메서드는 컴파일되기 위해 큐에서 대기한다. 이후 메서드들은 컴파일 스레드에 의해 컴파일된다.
• 아주 오랫동안 돌아가는 루프 문의 카운터가 임계치를 넘어가면 해당 루프는 컴파일 대상이 된다. JVM은 루프를 위한 코드의 컴파일이 끝나면 루프가 다시 반복될 때는 코드를 컴파일된 코드로 교체하고 더 빠르게 실행된다. 이 교체 과정을 "스택 상의 교체(on-stack replacement, ORS)"라고 부른다.

컴파일 임계치(Compile Threshold) : JIT 컴파일러가 메소드가 자주 사용되는지 체크하는 방식으로 컴파일 임계치를 사용한다. JIT 컴파일러가 내부적으로 메서드가 호출될 때마다 호출 횟수를 카운팅하고 그 횟수가 특정 수치를 초과할 때 캐싱헤서 이후에는 JIT 컴파일이 트기러된다.

[ 이점 ]

일반적인 인터프리터 언어는 바이트코드나 소스코드를 최적화 과정이 없이 번역하기 때문에 성능이 낮다. 반면 정적으로 컴파일하는 언어는 실행 전에 무조건 컴파일을 해야 하기 때문에 다양한 플랫폼에 맞게 컴파일을 하려면 시간이 오래 걸린다. JIT 컴파일러는 실행 과정에서 컴파일을 할 수 있기 위해 만들어졌다. JIT 컴파일러는 정적 컴파일러만큼 빠르면서 인터프리터 언어의 빠른 응답속도를 추구하기 위해 사용한다. 또한 바이트코드 컴파일러가 시간이 많이 소요되는 최적화를 미리 해주기 때문에 바이트 코드에서 기계어 번역은 훨씬 빠르게 진행될 수 있어 성능상의 이점이 있다.

0310 - 자바에서 병렬 스트림을 사용하는 경우

Java 8에서는 컬렉션 데이터 스트림으로 쉽게 반복할 수 있는 Stream API를 도입했다.

순차 스트림

• 단일 스레드 처리

List<Integer> listOfNumbers = Arrays.asList(1, 2, 3, 4);
listOfNumbers.stream().forEach(number ->
    System.out.println(number + " " + Thread.currentThread().getName())
);

실행결과 :
1 main
2 main
3 main
4 main

병렬 스트림

List<Integer> listOfNumbers = Arrays.asList(1, 2, 3, 4);
listOfNumbers.parallelStream().forEach(number ->
        System.out.println(number + " " + Thread.currentThread().getName())
);

4 ForkJoinPool.commonPool-worker-3
2 ForkJoinPool.commonPool-worker-5
1 ForkJoinPool.commonPool-worker-7
3 main

[ Fork-Join Framework ]

병렬 스트림은 Fork-Join 프레임워크와 common pool of worker 스레드를 사용한다. fork-join 프레임워크는 여러 스레드간의 작업 관리를 처리하기 위해 Java7의 java.util.concurrent에 추가되었다.

[ 소스 분할 ]

fork-join 프레임워크는 worker 스레드간에 소스 데이터를 분할하고 작업 완료시 콜백을 처리하는 역할을 한다.

List<Integer> listOfNumbers = Arrays.asList(1, 2, 3, 4);
int sum = listOfNumbers.parallelStream().reduce(5, Integer::sum);
assertThat(sum).isNotEqualTo(15);

순차스트림에서의 작업 결과는 15이나, 병렬 처리시 실제 모든 워커 스레드에서 숫자 5가 합산된다.

List<Integer> listOfNumbers = Arrays.asList(1, 2, 3, 4);
int sum = listOfNumbers.parallelStream().reduce(0, Integer::sum) + 5;
assertThat(sum).isEqualTo(15);

병렬 스트림 외부에 숫자 5를 더하는 작업을 통해 문제 해결

[ common thread pool ]

common 스레드풀의 스레드 수는 프로세서 코어 수와 같다. 그러나 API를 사용하면 JVM 매개변수를 전달하여 사용할 스레드수를 지정할 수 있다.

-D java.util.concurrent.ForkJoinPool.common.parallelism=4

이것은 전역으로 설정하는 것이며, common thread pool을 사용하는 모든 병렬 스트림 및 기타 모든 fork-join 작업에 영향을 미친다. 사용시 주의

[ custom thread pool ]

List<Integer> listOfNumbers = Arrays.asList(1, 2, 3, 4);
ForkJoinPool customThreadPool = new ForkJoinPool(4);
int sum = customThreadPool.submit(
    () -> listOfNumbers.parallelStream().reduce(0, Integer::sum)).get();
customThreadPool.shutdown();
assertThat(sum).isEqualTo(10);

[ 성능상의 영향 ]

병렬 처리는 다중 코어를 온전히 활용할 수 있다. 그러나 다중 스레드 관리, 메모리 지역성, 소스 분할 및 결과 병합에 대한 오버헤드도 고려해야 한다.

[ 오버헤드(Overhead) ]

IntStream.rangeClosed(1, 100).reduce(0, Integer::sum);
IntStream.rangeClosed(1, 100).parallel().reduce(0, Integer::sum);

이런 간단한 합계에서 순차 스트림을 병렬 스트림으로 변환하면 성능이 저하된다.

그 이유는 때때로 스레드, 소스 및 결과를 관리하는 오버헤드가 실제 작업을 수행하는 것보다 cost가 많이 드는 작업이기 때문이다.

[ 분할 비용(Splitting Costs) ]

데이터 소스(각각의 스트림 단위)를 균등하게 분할하는 것은 병렬 처리를 하는데 필요한 cost이지만 일부 데이터 소스는 다른 데이터 소스보다 더 잘분할 된다.

private static final List<Integer> arrayListOfNumbers = new ArrayList<>();
private static final List<Integer> linkedListOfNumbers = new LinkedList<>();

// 해당 코드로 100만의 정수 목록을 초기화합니다.
static {
    IntStream.rangeClosed(1, 1_000_000).forEach(i -> {
        arrayListOfNumbers.add(i);
        linkedListOfNumbers.add(i);
    });
}

arrayListOfNumbers.stream().reduce(0, Integer::sum)
arrayListOfNumbers.parallelStream().reduce(0, Integer::sum);
linkedListOfNumbers.stream().reduce(0, Integer::sum);
linkedListOfNumbers.parallelStream().reduce(0, Integer::sum);

아래의 결과는 순차 스트림을 병렬 스트림으로 변환하는 것이 ArrayList에 대해서만 성능 이점을 가져온다는 것을 보여준다.

LinkedList는 병렬처리를 했지만 Scoredhk Error 값이 증가, 반면 ArrayList는 Score와 Error 값이 감소

그 이유는 Array라는 특징이 저렴하게 소스를 분할할 수 있지만 LinkedList에는 이러한 속성이 없기 때문이다. TreeMap과 HashSet은 LinkedList보다 잘 분할되지만 Array만큼은 분할되지 안흔다.

[ 병합 비용(Merging Costs) ]

병렬 계산을 하기 위해 소스를 분할할 때마다 결국 결과를 병합해야 한다. 서로 다른 병합 작업으로 sum 및 grouping을 사용하여 순차 및 병렬 스트림에서의 성능 테스트를 실행

arrayListOfNumbers.stream().reduce(0, Integer::sum);
arrayListOfNumbers.stream().parallel().reduce(0, Integer::sum);
arrayListOfNumbers.stream().collect(Collectors.toSet());
arrayListOfNumbers.stream().parallel().collect(Collectors.toSet());

아래의 결과는 순차 스트림을 병렬 스트림으로 변환하는 것이 sum 연산에 대해서만 성능상의 이점을 가져온다는 것을 보여준다.

병합 작업은 reduce와 sum과 같은 일부 작업의 경우 정말 가볍게 동작하지만 set과 map과 같은 형태로 그룹화하는 것은 병합 작업이 상당히 무겁게 동작할 수 있다.

[ Memory Locality ]

최신 컴퓨터는 정교한 멀티 레벨 캐시를 활용하여 자주 사용하는 데이터를 프로세서 가까이에 저장한다. 선형 메모리 엑세스 패턴이 감지되면 하드웨어는 곧 필요할 것이라는 가정 하에 다음 데이터 라인을 미리 가져온다.(prefetch)
병렬 처리는 프로세서 코어가 유용한 작업을 지속적으로 처리할 수 있을 때 성능 이점을 가져온다. cache miss를 기다리는 것은 유용한 작업이 아니기 때문에 메모리 대역폭을 제한 요소로 고려해야 한다.
하나는 primitive 타입을 사용하고 다른 하나는 wrapper 타입을 사용하는 두개의 배열을 사용하여 이를 증명하는 예이다.

private static final int[] intArray = new int[1_000_000];
private static final Integer[] integerArray = new Integer[1_000_000];

static {
    IntStream.rangeClosed(1, 1_000_000).forEach(i -> {
        intArray[i-1] = i;
        integerArray[i-1] = i;
    });
}

두 배열에서 순차 및 병렬 reduce 작업에 대한 성능 테스트를 실행해보자

Arrays.stream(intArray).reduce(0, Integer::sum);
Arrays.stream(intArray).parallel().reduce(0, Integer::sum);
Arrays.stream(integerArray).reduce(0, Integer::sum);
Arrays.stream(integerArray).parallel().reduce(0, Integer::sum);

아래의 결과 순차 스트림을 병렬 스트림으로 변환하는 것이 primitive 배열을 사용할 때 약간 더 많은 성능 이점을 가져온다.

[ NQ모델 ]

NQ모델에서는 N은 소스 데이터의 요소 수를 나타내고 Qs는 데이터 요소당 수행된 계산의 양을 나타낸다.
N * Q의 곱이 클수록 병렬화로 인해 성능 향상의 가능성이 높아진다. 숫자 합산과 같이 사소한 Q가 있는 문제의 경우 경험상 N은 10,000 보다 커야 한다.

0317 - JMH(Java Microbenchmark Harness)

JMH는 JVM 위에서 동작하는 코드의 성능을 측정해주는 라이브러리다. 사실 정확한 성능을 측정하기 위해선 사용하는 가상머신의 제품에 따라 Hot-Spot VM 오버헤드나 GC 오버헤드와 같은 코드가 동작함에 있어서 시스템의 오버헤드까지 고려해서 측정해야 하지만 간단한 코드이거나 여러 코드의 상대적 성능을 측정할 때에는 간단히 사용할 수 있는 JMH를 사용할 수 있다.

참고로, JMH는 Oracle의 JIT Compiler 개발자가 만든 것이기 때문에 타 벤치마크 프레임워크보다 신뢰할 수 있다.

[ 사용방법 ]

plugins {
  id "me.champeau.jmh" version "0.7.0"
}

dependencies {
    jmh 'org.openjdk.jmh:jmh-core:0.9'
    jmh 'org.openjdk.jmh:jmh-generator-annprocess:0.9'
}

@State(Scope.Thread)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
public class LoopTest {

    final LIMIT_COUNT = 10000;
    final List<Integer> array = new ArrayList<>();

	@Setup
	public void init() {
        // 성능 측정 전 사전에 필요한 작업
        for(int i = 0; i < LIMIT_COUNT; i++) {
            array.add(i);
        }
	}

	@Benchmark
	public void originLoopWithGetSize() {
        // 성능을 측정할 코드 작성
        int size = array.size();
        for(int i = 0; i < size; i++) {
            processor(i);
        }
	}

    Integer temp = 0;
    public void processor(Integer i) {
        temp = i;
    }

    public static void main(String[] args) throws IOException, RunnerException {
        Options opt = new OptionsBuilder()
                .include(LoopTest.class.getSimpleName())
                .warmupIterations(10)           // 사전 테스트 횟수
                .measurementIterations(10)      // 실제 측정 횟수
                .forks(1)                       // 
                .build();
        new Runner(opt).run();                  // 벤치마킹 시작
    }
}

# Run complete. Total time: 00:01:43

Benchmark                       Mode  Cnt  Score   Error  Units
LoopTest.forEach                avgt   10  0.990 ± 0.096  ms/op
LoopTest.forEachByJdk8          avgt   10  0.703 ± 0.160  ms/op
LoopTest.forEachByStream        avgt   10  0.561 ± 0.057  ms/op
LoopTest.originLoop             avgt   10  0.634 ± 0.117  ms/op
LoopTest.originLoopWithGetSize  avgt   10  0.876 ± 0.093  ms/op

0319 - KPI/SLI/SLO/SLA

1. KPI(Key Performance Indicator)

KPI(Key Performance Indicator)는 성공을 측정하는데 사용될 수 있는 메트릭이다.

• KPI는 목표나 목적과는 다른, 목표르르 달성하는 과정 중에 있는지 측정하는 메트릭이다. 따라서 수반하는 목표가 필요하다. 또한, KPI를 모니터링하는 것은 목표를 달성하기 위해 필수적이다.
• SMART 법칙
  • Specific : KPI는 구체적이어야 한다.
  • Measurable : 모니터링하기 위해서 KPI는 측정 가능해야 한다.
  • Acheivable : 100%는 성취하기 어렵다.
  • Relevant : 관련있지 않은 KPI는 목표 달성을 이끌어 낼 수 없다.
  • Time-bound : 99% availble- Per year? Per month? Per day?

2. Service Level

Indicators -> Objectives -> Agreement

[ SLI(Service Level Indicators) ]

: 서비스의 측정 가능한 특성, A KPI
ex. Availability

SLI는 시간이 정해지고 측정 가능해야 한다.

[ SLO(Service Level Objectives) ]

: 주어진 SLI로 성취하고 싶은 목표나 숫자 지표
ex. 95%, 99% or 99.99% availability

SLO는 성취 가능하고 관련 있어야 한다.
가능한 높은 목표를 세우는 것이 아니라, 사용자를 만족시킬 만큼에서 가격 효율적인 SLO를 선택해야한다. SLO가 높을수록 높은 비용과 노력을 초래하기 때문이다.
SLO를 최소화 해야한다. 그리고 어플리케이션이 SLO를 크게 능가해서는 안된다.

[ SLA(Service Level Agreements) ]

: 만약 서비스가 특정 기대를 못 미쳤을 때, 고객 보상을 제공해주는 구속력있는 계약
= more restrictive version of SLO

SLA에는 만약 서비스가 특정 가용성을 또는 퍼포먼스 기준을 유지하지 못했을때 제공자에 가해지는 penalty에 대하여 적는다. 그리고 SLA가 깨지면, 고객은 제공자로부터 보상을 받는다.

모든 서비스에 SLA가 있어야 하는 것은 아니지만, SLO는 있어야 한다. SLO의 기준은 SLA보다 높아야한다.