V8가 실제 성능을 측정하는 방법

지난 1년 동안 V8 팀은 실제 JavaScript 성능을 측정하고 이해하기 위한 새로운 방법론을 개발했습니다. 이를 통해 얻은 통찰력을 바탕으로, V8 팀이 JavaScript를 더욱 빠르게 만들기 위한 방식을 변화시켰습니다. 우리의 새로운 실제 환경 중심의 접근법은 전통적인 성능 중심에서 중요한 변화의 순간을 나타냅니다. 2017년에도 이 방법론을 계속 적용하면서, Chrome과 Node.js 모두에서 실제 JavaScript를 위한 예측 가능한 성능에 의존할 수 있는 사용자와 개발자의 능력을 크게 향상시킬 것이라고 확신합니다.

옛 격언 "측정되는 것은 개선된다"는 JavaScript 가상 머신(VM) 개발 세계에서 특히 진실합니다. 올바른 성능 최적화 지표를 선택하는 것은 시간이 지남에 따라 VM 팀이 할 수 있는 가장 중요한 일 중 하나입니다. 다음 타임라인은 V8의 초기 출시 이후 JavaScript 벤치마크가 어떻게 발전했는지 대략적으로 보여줍니다:

역사적으로, V8 및 기타 JavaScript 엔진은 인공 벤치마크를 사용하여 성능을 측정해왔습니다. 초기에는 VM 개발자들이 SunSpider와 Kraken과 같은 마이크로 벤치마크를 사용했습니다. 브라우저 시장이 성숙하면서, 좀 더 크지만 여전히 인공적인 테스트 스위트인 Octane과 JetStream과 같은 두 번째 벤치마크 시대가 시작되었습니다.

마이크로 벤치마크와 정적 테스트 스위트는 몇 가지 이점이 있습니다: 부트스트랩이 용이하고, 이해하기 간단하며, 어떤 브라우저에서도 실행 가능해 비교 분석이 쉽다는 점입니다. 그러나 이러한 편리함에는 몇 가지 단점이 따릅니다. 테스트 케이스가 제한적이기 때문에 웹 전체의 특성을 정확히 반영하는 벤치마크를 설계하기 어렵습니다. 게다가, 벤치마크는 보통 자주 업데이트되지 않기 때문에 JavaScript 개발의 새로운 트렌드와 패턴을 따라가기 어렵습니다. 마지막으로, 몇 년에 걸쳐 VM 저자들은 기존 벤치마크의 모든 구석구석을 탐구하여 때로는 외부에서 관찰할 수 없는 작업을 벤치마크 실행 중 생략하거나 재배치하는 방식으로 벤치마크 점수를 향상시킬 기회를 발견하고 활용했습니다. 이러한 벤치마크 점수 중심 개선 및 벤치마크에 과도하게 최적화하는 것은 사용자나 개발자에게 실질적인 이익을 제공하지 않는 경우가 많으며, 역사가 보여주듯 장기적으로 "게임 불가능한" 인공 벤치마크를 만드는 것은 매우 어렵습니다.

실제 웹사이트 측정: WebPageReplay 및 Runtime Call Stats

전통적인 정적 벤치마크는 성능 이야기의 한 부분만 보여준다라는 직감을 바탕으로, V8 팀은 실제 웹사이트 로드를 벤치마크하여 현실 세계의 성능을 측정하려는 목표를 세웠습니다. 우리는 최종 사용자가 실제로 웹을 탐색하는 방식을 반영하는 사용 사례를 측정하고 싶었으며, 트위터, 페이스북 및 구글 지도와 같은 웹사이트에서 성능 메트릭을 도출하기로 했습니다. WebPageReplay라는 Chrome 인프라를 사용하여 페이지 로드를 결정적으로 기록하고 재생할 수 있었습니다.

동시에, 각기 다른 JavaScript 코드가 어떻게 서로 다른 V8 구성 요소에 스트레스를 주는지를 프로파일링할 수 있는 Runtime Call Stats라는 도구를 개발했습니다. 이 덕분에 우리는 V8 변경 사항을 실제 웹사이트에 쉽게 테스트할 수 있을 뿐만 아니라, 서로 다른 워크로드에서 V8이 다르게 작동하는 이유와 방법을 완전히 이해할 수 있는 능력을 갖추었습니다.

현재 우리는 약 25개 웹사이트로 구성된 테스트 스위트를 기반으로 V8 최적화를 가이드하기 위해 변경 사항을 모니터링하고 있습니다. 앞서 언급된 웹사이트 및 Alexa Top 100에 있는 다른 웹사이트 외에도, 우리는 공통 프레임워크(React, Polymer, Angular, Ember 등)를 사용하여 구현된 웹사이트, 다양한 지리적 위치의 웹사이트, 위키피디아, Reddit, 트위터 및 Webpack과 같이 개발팀이 우리와 협력한 웹사이트 또는 라이브러리를 선택했습니다. 우리는 이 25개 웹사이트가 웹 전반을 대표하며, 이 사이트의 성능 향상이 현재 JavaScript 개발자가 쓰고 있는 유사한 사이트의 속도 향상에 직접적으로 반영될 것이라고 믿습니다.

우리의 웹사이트 테스트 스위트 및 Runtime Call Stats 개발에 대한 심층적인 프레젠테이션을 보려면 BlinkOn 6에서 발표된 현실 성능 프레젠테이션을 참고하세요. Runtime Call Stats 도구를 직접 실행해볼 수 있습니다.

실제적인 변화를 이끌어내기

Runtime Call Stats를 사용하여 이러한 새로운 실제 환경 성능 지표를 분석하고 이를 전통적인 벤치마크와 비교함으로써, 다양한 작업 부하가 V8에 미치는 스트레스가 어떻게 다른지를 보다 깊이 이해할 수 있게 되었습니다.

이 측정 결과를 통해, Octane 성능이 우리가 테스트한 25개 웹사이트 중 대다수에 대한 성능의 적절한 대리 기준이 되지 못한다는 사실을 발견했습니다. 아래 차트에서 볼 수 있듯이, Octane의 색상 막대 분포는 특히 실제 환경 웹사이트와 다른 작업 부하에 비해 매우 다릅니다. Octane을 실행할 때 V8의 병목 현상은 종종 JavaScript 코드 실행에서 발생하지만, 대부분의 실제 웹사이트는 V8의 파서 및 컴파일러를 더 많이 사용합니다. 우리는 Octane에 대한 최적화 작업이 실제 웹 페이지에 큰 영향을 미치지 못하거나, 경우에 따라 실제 웹사이트를 더 느리게 만들었다는 사실을 깨달았습니다.

또 다른 벤치마크가 실제 웹사이트에 더 적합한 대리 기준이라는 사실도 발견했습니다. React, Angular, Ember 및 기타 프레임워크로 작성된 애플리케이션을 포함하는 WebKit 벤치마크 Speedometer는 25개 사이트와 매우 유사한 실행 성능을 보였습니다. 어떤 벤치마크도 실제 웹 페이지의 정확도를 완벽히 재현할 수는 없지만, Speedometer는 Octane보다 현대 JavaScript의 실제 작업 부하를 더 잘 근사한다고 생각합니다.

결론: 모두를 위한 더 빠른 V8

지난 1년에 걸쳐, 실제 웹사이트 테스트 스위트와 Runtime Call Stats 도구를 통해 페이지 로드를 평균 10-20% 더 빠르게 만드는 V8 성능 최적화를 구현할 수 있었습니다. 크롬의 페이지 로드 최적화에 대한 역사적인 초점을 고려할 때, 2016년에 이 지표를 두 자릿수로 개선한 것은 중요한 성과입니다. 같은 최적화는 Speedometer 점수도 20-30% 개선했습니다.

이런 성능 개선은 현대 프레임워크를 사용하고 유사한 JavaScript 패턴을 사용하는 웹 개발자가 작성한 다른 사이트에서도 반영될 것입니다. Object.create와 Function.prototype.bind와 같은 내장 기능의 개선, 객체 팩토리 패턴 주위의 최적화, V8의 인라인 캐시 작업, 지속적인 파서 개선은 우리가 추적하는 대표적인 사이트뿐만 아니라 모든 개발자가 사용하는 JavaScript의 간과된 영역에 대한 일반적으로 적용 가능한 개선을 목적으로 하고 있습니다.

우리는 V8 성능 작업을 안내하기 위해 실제 웹사이트 사용을 확대할 계획입니다. 벤치마크와 스크립트 성능에 대한 더 많은 인사이트를 기대해주세요.