Netflix에서 Java 서비스를 vCPU 16개에서 vCPU 48개로 올리면서 3배의 성능 향상을 기대했지만 처리량은 25%만 증가하고 지연시간도 오히려 증가하는 문제를 발견하고 이를 트러블 슈팅한 과정입니다. 매트릭을 살펴보던 중 CPU와 대기 시간이 낮은 노드가 있다는 것을 발견하고 PMC를 통해 더 낮은 수준의 매트릭을 살펴보다가 2개의 코어가 동일한 L1 캐시 라인을 공유하면서 관련 없는 변수를 읽고 쓸 때 발생하는 False Sharing의 일반적인 패턴을 반결한 수 있었다고 합니다. 이를 해결하기 위해 JDK의 통작을 수정하지 않고 데이터 레이아웃에 패딩을 추가해서 느린 노드의 문제를 해결했습니다. 하지만 여전히 목표였던 250RPS에는 못 미치는 150 RPS만 처리할 수 있었는데 이는 동일한 변수를 여러 스레드/코어에서 읽고 쓰는 True Sharing 문제임을 알게 되어 공유 변수에 모두 쓰는 대신 JVM의 보조 슈퍼클래스 캐시를 효과적으로 우회하도록 수정해서 결과적으로 3.5배의 성능 향상을 이루었다고 합니다.