Internet Explorer 성능 랩: 신뢰할 수 있는 브라우저 성능 측정
이 블로그에서 중점을 두는 부분은 잘 알려지지 않은 Windows 8의 개발 정보를 여러분들에게 공개하는 것입니다. 이 글에서는 엔지니어나 최종 사용자 모두 현실적으로 매우 높은 관심을 보이는 주제인 실제 사용 환경에서의 웹 성능에 대해 알아봅니다. 우리는 고성능 웹 브라우징을 구현하는 과정에서 개인적인 사소한 경험이나 느낌 정도의 기본적 문제를 넘어선 보다 높은 가치를 실현하기 위해 엄청난 노력을 기울이고 있습니다. 성능 문제는 모든 IE 팀원들이 노력을 기울이는 부분이며, 이 글은 IE 팀에 소속된 Matt Kotsenas, Jatinder Mann 및 Jason Weber가 작성했습니다. - Steven
웹 성능은 누구에게나 중요한 문제이고 Internet Explorer가 추구하는 단 하나의 개발 목표는 바로 세계에서 가장 빠른 브라우저가 되는 것입니다. 이 목표를 달성하기 위해서는 고객에게 중요한 실제 사용 환경에서 브라우저 성능을 신뢰도 높게 측정해야 합니다. 지난 5년에 걸쳐 우리는 세계에서 가장 발전된 웹 성능 측정 시스템 중 하나인 Internet Explorer 성능 랩을 설계하고 구축했습니다.
IE 성능 랩은 전체 개발 과정에서 의사 결정에 유용한 정보로 활용될 수 있도록 신뢰할 수 있고 정확하며 조정 가능한 데이터를 수집합니다. 하루 200회에 걸쳐 Internet Explorer 성능이 측정되는데 이 과정에서 570만 개의 측정 데이터가 수집되고 하루 실행 데이터만 480GB에 달합니다. 개발 팀은 Internet Explorer의 속도를 더욱 높이는 부분에 중점을 두고 제품 변경에 따른 영향을 세심하게 점검합니다. 이 블로그 글에서는 IE 성능 랩이 설계된 방식과 함께 웹 속도를 지속적으로 개선하기 위해 이 랩이 어떤 도움을 주는지 깊이 있게 살펴보려고 합니다.
이 글에서는 다음 내용을 다룹니다.
- IE 성능 랩 개요
- 랩 인프라
- 측정 내용 및 방법
- 시나리오 테스트
- 결과 조사
- 타사 소프트웨어 테스트
- 사용자를 위한 빠른 브라우저 구축
IE 성능 랩 개요
시간에 따른 웹 성능을 높은 신뢰도로 측정하기 위해서는 시스템이 실제 사용자의 시나리오를 사실적으로 시뮬레이션할 수 있어야 합니다. 기본적으로, 이 시스템에서는 '인터넷 축소판'을 만들어야 합니다.
IE 성능 랩은 공용 인터넷뿐만 아니라 Microsoft 인트라넷 네트워크와도 완전히 분리된 사설 네트워크이며 140대 이상의 시스템을 포함합니다. 이 랩에서는 웹 서버, DNS 서버, 라우터 및 다양한 고객 연결 시나리오를 시뮬레이션하는 네트워크 에뮬레이터 등 실제 인터넷의 핵심 요소들이 이용됩니다.
이러한 환경이 얼핏 복잡해 보일 수도 있지만 이렇게 해야 최대한 변수를 없앨 수 있습니다. 개별 패킷의 호핑 및 대기 시간까지 세부적으로 네트워크의 모든 측면을 통제하여 테스트의 확정성과 재현성을 높임으로써 결과를 실제 환경에 적용할 수 있는 타당성이 향상됩니다. IE 성능 랩에서 작동 상태는 100나노초 분해능으로 측정됩니다.
이러한 형태의 네트워크 구성은 유연성도 크게 높입니다. 실제 설정 환경을 시뮬레이션하는 것이기 때문에 성능 랩에서는 모든 형태의 테스트 시스템 또는 웹 사이트 콘텐츠를 처리할 수 있습니다. IE 성능 랩은 x86, x64 및 ARM 프로세서를 탑재한 데스크톱, 랩톱, 넷북 및 태블릿을 모두 동시에 지원합니다. 마찬가지로, 랩에서는 Windows 성능 도구(WPT)를 사용하기 때문에 다양한 웹 브라우저, 도구 모음, 바이러스 백신 제품 또는 타사 소프트웨어를 사용하여 동일 테스트를 실행하고 결과를 직접 비교할 수 있습니다.
WPT는 기본 하드웨어에 대한 깊은 통찰력을 제공합니다. WPT를 사용하면 고레벨 CPU 및 GPU 작동부터 캐시 효율, 네트워킹 통계, 메모리 사용 패턴 등의 저레벨 정보까지 모두 포착할 수 있습니다. WPT를 사용하면 전 스택에 걸쳐 성능을 측정하고 최적화하여 하드웨어, 장치 드라이버, Windows 운영 체제 및 Internet Explorer 모두를 효과적으로 최적화할 수 있습니다.
한 번 테스트를 실행하는 데 6시간이 걸리며 이 시간 동안 22GB 이상의 데이터가 생성됩니다. 고도로 자동화된 이 시스템은 작동을 모니터링하고 결과를 분석하며 새로운 인프라 기능을 개발하는 소규모 팀에 의해 운영됩니다.
랩 인프라
성능 랩 인프라는 크게 3가지 범주로 나눌 수 있습니다. 바로 '네트워크 및 서버', '테스트 클라이언트' 및 '분석 및 보고'입니다. 각 범주는 테스트의 확장성을 개선하고 랩 환경에 노이즈가 유입될 가능성을 줄이는 데 목적을 두고 구성 요소 사이의 상호 작용을 최소화하도록 설계되었습니다.
사설 네트워크에서 운영되는 많은 테스트 및 분석 시스템이 갖춰진 IE 성능 랩의 모습입니다.
네트워크 및 서버 인프라
우선 소규모 인터넷을 구성하는 요소들인 DNS 서버, 네트워크 에뮬레이터 및 콘텐츠 서버에 대해 설명하겠습니다. 아래에 나오는 3가지 섹션에 대해 위 구조도의 오른쪽에서 왼쪽 방향으로 진행하면서 살펴보겠습니다.
콘텐츠 서버
콘텐츠 서버는 인터넷에 존재하는 수백만 개의 웹 호스트에 이용되는 웹 서버입니다. 각 콘텐츠 서버는 로컬로 캡처된 실제 웹 페이지를 호스팅합니다. 캡처된 페이지는 웹 콘텐츠의 각 부분에 재현 결정성을 부여하기 위한 처리 과정인 '위생 처리(sanitization)'라고 하는 프로세스를 거칩니다. 예를 들어, JavaScript Date 함수나 Math.Random() 호출은 정적 값으로 대체됩니다. 또한, 광고 프레임워크에 의해 생성된 동적 URL은 이 프레임워크에 의해 처음 만들어졌던 URL로 고정됩니다.
위생 처리를 거친 후, 콘텐츠는 마찬가지로 URL 해시를 콘텐츠에 매핑하는 ISAPI 필터를 통해 정적 콘텐츠에 제공되어 이를 즉각적으로 볼 수 있게 합니다. 각 웹 서버는 가변성을 최소화하고 콘텐츠를 메모리에 유지하기 위해(디스크 액세스 불필요) 16GB의 RAM을 탑재한 16코어의 높은 시스템 사양을 가지고 있습니다.
콘텐츠 서버는 Outlook Web Access 또는 Office Web Apps 등의 동적 웹 앱도 호스팅할 수 있습니다. 이러한 경우, 응용 프로그램 서버와 다중 계층 종속성은 실제 환경을 모방하여 랩에 있는 전용 서버에서 호스팅됩니다.
네트워크 에뮬레이터
많은 가변성 요인을 제거했기 때문에 네트워크 속도에는 더 이상 연결 속도가 느린 많은 사용자 경험을 반영하지 않습니다. 실제 사용자 환경을 시뮬레이션하기 위해 테스트에 네트워크 에뮬레이션을 도입함으로써 현재 사용 중인 광범위한 네트워크에서 경험하는 성능을 이해할 수 있습니다. 랩에서는 다수의 DSL 구성, 케이블 모뎀, 56K 모뎀뿐만 아니라 WAN 및 4G 환경과 같이 대역폭이 크고 대기 시간이 긴 환경의 에뮬레이션도 지원합니다. HTTP 요청이 에뮬레이터로 전달되면 에뮬레이터는 패킷 지연 및 재구성 같은 네트워크 특성을 시뮬레이션한 다음, 웹 호스트로 요청을 전달합니다. 응답이 수신되면 에뮬레이션이 다시 적용된 후 테스트 클라이언트로 다시 전달됩니다.
네트워크 에뮬레이션에 전용 하드웨어를 사용하므로 현실과 가장 잘 부합하는 테스트 환경을 제공하며 관찰자 효과를 크게 줄일 수 있습니다. 전용 하드웨어를 이용하는 방법은 프록시 또는 소프트웨어 기반 솔루션에 비해 비용이 많이 들고 더 복잡하지만 성능을 정확하게 측정하는 유일한 방법입니다. 브라우저는 프록시 포화를 방지하기 위해 동시 프록시 연결 수를 제한하기 때문에 네트워크 에뮬레이션에 프록시를 사용하면 웹 페이지에 의한 도메인 샤딩(sharding)과 기타 최적화를 회피하는 의도하지 않은 효과가 나타납니다. 또한, 로컬 네트워크 에뮬레이션은 특히 절전 시스템의 경우에 로컬 시스템 리소스를 놓고 브라우저와 경합하게 됩니다.
DNS 서버
실제 DNS 서버와 마찬가지로 랩의 DNS 서버도 콘텐츠 서버를 테스트 클라이언트에 연결시킵니다. 또한 랩에서는 각 네트워크 에뮬레이터에 서로 다른 DNS 서버를 사용하므로 간단히 DNS 서버를 바꾸어 네트워크 속도를 변화시킬 수 있습니다. 이러한 경우에 DNS 서버는 웹 호스트에 대한 도메인 이름을 확인하는 대신 관련된 네트워크 에뮬레이터에 대한 모든 도메인 이름을 확인합니다.
테스트 클라이언트 구성
Internet Explorer가 어떤 부류의 컴퓨터 하드웨어에서도 변함 없이 빠르게 실행되도록 하는 것이 우리의 목표입니다. 랩에는 Internet Explorer 성능을 측정하는 데 사용되는 120대 이상의 컴퓨터가 있습니다. 랩에서는 이러한 컴퓨터를 테스트 클라이언트라고 부르며 종류도 고급형 x64 데스크톱부터 저전력 넷북, 터치 방식의 태블릿 장치 및 그 중간 형태 등 다양합니다. 무엇보다 측정의 재현성이 중요하기 때문에 모든 테스트에 실제 클라이언트 시스템이 이용됩니다.
Internet Explorer 성능 랩의 변경 비교 시스템 풀
각 부류의 시스템에는 Internet Explorer가 전체 장치 환경의 하드웨어 가속을 완벽하게 활용하도록 전용 및 통합 그래픽 플랫폼이 모두 포함됩니다. 위 사진은 기본 시스템 풀입니다. 이러한 PC는 Windows 7 또는 Windows 8 PC 사용 기간 동안 소비자의 일반적 사용 환경을 대략적으로 시뮬레이션합니다. 이러한 시스템은 OEM을 통해 동일하게 주문되고 모두 동일한 제조 로트 번호를 가지고 있으며 사용 전에 성능 특성을 테스트합니다.
랩이 365일 24시간 가동되기 때문에 하드웨어 고장은 불가피합니다. 고장 난 부품을 다른 제조 로트 번호를 가진 동일 부품으로 교체하면 거의 예외 없이 수리한 컴퓨터가 풀에 있는 다른 시스템보다 빠르게 작동합니다. 이러한 차이는 실제 환경에서는 감지할 수 없는 수준이지만 100나노초 단위로 측정하는 상황에서는 몇 번의 주기만 돌아도 결과에 영향을 미칠 수 있습니다! 수리 후 시스템이 더 이상 풀의 나머지 시스템과 동일하게 작동하지 않으면 이 시스템이 랩에서 제거되고 풀의 규모가 영구적으로 축소됩니다. 이러한 상황에 대비하여 랩에서 시스템을 구입할 때 '예비' 시스템을 함께 구입하기 때문에 풀에서 고장 난 시스템을 제거해도 추가 시스템이 완충 역할을 하여 랩 운영에 차질을 빚지 않을 수 있습니다.
풀 이름 |
시스템 수 |
폼 팩터 |
프로세서 |
아키텍처 |
클럭 속도 |
RAM |
그래픽 |
기본 풀 |
32 |
데스크톱 |
코어 i5 750(Lynnfield) |
64비트 |
2.66GHz |
4096MB DDR3 |
NVIDIA GeForce 310 |
하드웨어의 범위를 넓히기 위해 다양한 사용자 시나리오를 포괄하는 추가 시스템 풀이 운영됩니다. 이러한 시스템에서 성능이 우수하면 IE가 전체 PC 에코시스템에 걸쳐 기본적 하드웨어를 효과적으로 이용하는 것입니다.
풀 이름 |
시스템 수 |
폼 팩터 |
프로세서 |
아키텍처 |
클럭 속도 |
RAM |
그래픽 |
고급 1 |
20 |
데스크톱 |
코어 i7 870 |
64비트 |
2.93GHz |
4096MB DDR3 |
ATI Radeon HD 4550 |
고급 2 |
4 |
데스크톱 |
Xeon 5150(Woodcrest) |
64비트 |
2.66GHz |
8192MB DDR2 |
ATI Radeon X1950 Pro |
중급 1 |
6 |
데스크톱 |
코어 2 Duo(Wolfdale) |
64비트 |
3.0GHz |
4096MB DDR2 |
Intel GMA 4500 |
중급 2 |
15 |
데스크톱 |
코어 2 Duo E6750 |
64비트 |
2.66GHz |
4096MB DDR2 |
ATI Radeon HD 2400 XT |
중급 3 |
25 |
데스크톱 |
코어 i5 2500 |
64비트 |
3.30GHz |
4096MB DDR3 |
Intel HD 그래픽 2000 |
중급 4 |
6 |
데스크톱 |
코어 2 Duo(Conroe) |
64비트 |
2.66GHz |
4096MB DDR2 |
ATI Radeon HD 2400XT |
중급 5 |
4 |
데스크톱 |
코어 2 Duo(Conroe) |
64비트 |
2.4GHz |
4096MB DDR2 |
ATI Radeon X1950 Pro |
저전력 1 |
2 |
랩톱 |
Atom Z530 |
32비트 |
1.6GHz |
2038MB DDR2 |
Intel GMA 500 |
저전력 2 |
4 |
넷북 |
Atom N270 |
32비트 |
1.6GHz |
1024MB DDR2 |
NVIDIA ION |
저전력 3 |
2 |
넷북 |
Atom N450 |
64비트 |
1.66GHz |
1024MB DDR2 |
Intel GMA 3150 |
저전력 4 |
4 |
넷북 |
Atom N270 |
32비트 |
1.6GHz |
1024MB DDR2 |
Intel GMA950 |
저전력 5 |
4 |
태블릿 |
ARM |
32비트 |
— |
— |
— |
프로토타입 하드웨어 |
— |
— |
— |
— |
— |
— |
— |
저전력 테스트 시스템.각 시스템은 각기 다른 테스트 상태에 있습니다.
추가적인 다양성이 요구되는 경우, IE 성능 랩은 Windows 그래픽 랩도 이용할 수 있습니다. Windows 그래픽 랩은 생산되는 거의 모든 그래픽 칩셋을 구비하고 있습니다. PC를 상상할 수 있는 거의 모든 가짓수로 구성하고 성능 테스트에 이용할 수 있습니다. Windows 그래픽 랩은 다양한 칩셋과 드라이버 버전에 걸쳐 그래픽 문제를 진단하는 매우 중요한 역할을 합니다.
분석 및 보고 서버
테스트 결과의 수집과 분석은 두 단계로 나뉘어 처리됩니다. 분석 작업을 전용 시스템에 전가시킴으로써 테스트 클라이언트는 다른 성능 테스트 작업을 보다 빠르게 시작할 수 있고 더욱 강력한 서버급 시스템에서 분석 작업을 빠르게 처리할 수 있습니다. 분석 작업이 빨리 끝날수록 더 효과적으로 성능 변화를 확인할 수 있습니다.
분석을 위해 랩에서는 11대의 서버급 시스템을 사용하며 각 시스템은 16개의 코어와 16GB의 RAM을 탑재하고 있습니다. 분석 과정에서 각 추적 파일을 검사하고 수천 가지의 평가 요소를 추출하여 SQL 서버에 입력시킵니다. 24시간 동안 이러한 분석 시스템은 15,000개 이상의 추적 데이터를 검사하여 경향 분석에 이용합니다.
여러 개의 랙 중 파일 서버, SQL 서버 및 여러 개의 분석 및 콘텐츠 서버를 포함한 두 개의 랙을 보여주는 사진입니다.
매일 수집되는 거의 600만 개의 측정 결과를 저장하는 데 사용되는 SQL Server는 64GB의 RAM과 24개의 논리 코어를 탑재한 시스템입니다. SQL에서 직접 보고서를 생성하거나 HTML 기반 비교 응용 프로그램, 또는 XML이나 JSON 형식의 결과를 제공하는 WCF 서비스를 이용하여 결과를 검토할 수 있습니다.
측정 내용 및 방법
인프라가 준비되었으므로 이제 성능 랩에서 측정되는 다양한 형태의 시나리오와 함께 평가 요소 수집에 이용하는 도구를 살펴보겠습니다.
매일 측정하는 시나리오
성능 랩은 사용자에게 실질적 중요성이 있는 시나리오에 중점을 둡니다. 따라서 하루에도 20,000건이 넘는 테스트를 실행합니다. 이러한 테스트는 때로 겹치기도 하는 4가지 범주로 분류됩니다.
콘텐츠 로딩(Loading content) – 웹 브라우저 내에서는 페이지 사이를 이동하는 것이 여전히 가장 일반적인 작업입니다. 웹 콘텐츠 로딩은 또한 대부분의 브라우저에서 11개 하위 시스템과 관련된 유일한 범주입니다. 웹 콘텐츠 로딩은 나머지 시나리오 범주에 대한 전제 조건입니다.
대화형 웹 앱(Interactive web apps) – 이 범주는 때로 콘텐츠 생성, AJAX 응용 프로그램 또는 Web 2.0 사이트라고도 하는 대상과 관련됩니다. 여기에는 인기 있는 뉴스 및 소셜 네트워킹 사이트와의 상호 작용뿐 아니라 Outlook Web Access 및 Office Web Apps 등의 메일 및 문서 응용 프로그램과의 상호 작용도 포함됩니다.
'응용 프로그램'으로서의 IE(IE “the application”) – 중요하지만 간과하는 경우가 많은 부분으로 브라우저 자체와의 상호 작용 시나리오가 있습니다. 일반적인 상호 작용으로는 브라우저 열기 또는 닫기, 탭 전환, 열어 본 페이지 목록 및 즐겨찾기 등의 브라우저 기능 사용, 그리고 키보드와 마우스 및 터치 입력을 사용한 이동과 확대/축소 등이 있습니다.
종합 벤치마크(Synthetic benchmarks) – 간과되는 경우는 거의 없지만 가끔 과장되기도 하는 요소로 WebKit SunSpider와 같은 종합 벤치마크가 있습니다. 각 브라우저 하위 시스템에 중점을 두고 브라우저 사이의 차이를 잘 드러내도록 고안되었다는 점에서 벤치마크는 유용한 개발 도구로 이용될 수 있습니다. 그러나 이러한 차이를 최대화하기 위해 벤치마크는 일반적이지 않은 사용 패턴이나 이례적 사례에 의존하는 경우가 있습니다.
실제 패턴
성능을 측정할 때는 테스트가 실제 사용 패턴을 반영하도록 하는 것이 중요합니다. 대부분의 소프트웨어 개발용 교재에는 이 프로세스가 WorkLoad 모델링 또는 응용 프로그램 사용 모델링으로 설명되어 있습니다. 실제 패턴을 측정하기 위해 성능 랩에서는 실제 패턴을 제공하고 다양한 브라우저 하위 시스템에서 실행되는 실제 웹 페이지를 사용합니다.
테스트에 사용할 사이트를 결정하기 위해 랩에서는 수백만 개의 사이트를 정기적으로 검색하여 사이트 속성과 코딩 패턴 목록을 정리합니다. 최종 DOM의 깊이와 폭, CSS 레이아웃 패턴, 사용된 공통 프레임워크 및 국제 기능 등 전체 사이트의 공통적 특징을 결정하기 위해 68가지 데이터 포인트가 사용됩니다. 그 결과를 바탕으로 우리는 광범위한 웹의 공통적 패턴과 다양성을 가장 잘 대표하는 사이트를 선택했습니다.
성능 평가 요소
성능에는 여러 가지 차원의 문제가 관련됩니다. 성능을 정확하게 파악하는 유일한 방법은 테스트 대상 시나리오의 본질을 파악하고 하드웨어와 OS가 브라우저와 상호 작용하는 방식을 이해하는 것입니다. 여기서는 주요 스포츠 사이트를 처음으로 로드하는 상황에서 중요하게 평가해야 할 5가지 성능 지표를 자세히 알아보겠습니다.
디스플레이 시간(Display Time) - 디스플레이 시간은 사용자가 작업을 수행한 다음 화면에서 이 작업의 결과를 볼 때까지의 시간을 측정합니다.
경과 시간(Elapsed Time) - 대부분의 사이트는 콘텐츠가 화면에 표시된 후 계속해서 배경 작업을 수행합니다. 웹 메일 응용 프로그램에서 다음 전자 메일을 다운로드하거나 제공자에게 분석 결과를 되돌려주는 것을 예로 들 수 있습니다. 사용자의 관점에서 사이트는 작업을 마친 것으로 보일 수 있지만 아직 많은 작업이 남아 있어 전체적 반응 속도에 영향을 미치는 경우가 많습니다.
CPU 시간(CPU Time) - 현재 이용되는 대부분의 웹 브라우저는 거의 예외 없이 CPU 속도의 제약을 받습니다. 일부 작업을 GPU로 전달하여 CPU 효율을 높이면 성능이 크게 향상됩니다.
리소스 사용률(Resource Utilization) - 빠른 브라우저를 개발한다는 것은 네트워크 사용률, 메모리 사용 패턴, GPU 처리, 그래픽, 메모리 및 수백 가지의 기타 차원을 포함하여 PC 전반에 걸쳐 리소스의 사용을 최적화하는 것을 의미합니다. 사용자는 PC에서 여러 응용 프로그램을 동시에 실행하기 때문에 브라우저가 이러한 리소스를 다른 응용 프로그램과 자율적으로 공유하는 것이 중요합니다.
전력 소모량(Power Consumption) - 전력 효율이 높으면 이동 시나리오에서 배터리 사용 시간이 늘어나고 장치의 전력 비용이 절감되며 환경에 미치는 영향이 줄어듭니다.
하나의 평가 요소에만 집중하다 보면 성능을 지나치게 단편적으로 보게 됩니다. 하나의 평가 요소만 고집하면 자연스럽게 이 평가 요소만 최적화하려는 경향이 생겨 마찬가지로 중요한 다른 평가 요소를 등한시 하게 되는 결과를 초래합니다. 이러한 경향에 빠지지 않으려면 성능의 모든 측면을 측정한 후 득실 관계를 균형적으로 유지하려는 의식적 노력이 반드시 필요합니다.
성능 랩에서는 총 850가지 이상의 평가 요소를 측정하는데, 이러한 각 평가 요소는 브라우저 성능의 일부분에 대한 정보를 제공합니다. 실제로 어떤 내용들이 측정되는지 알려드리면 이해가 쉬울 것 같습니다. 주요 평가 요소의 예: 개별 작업 집합, 총 작업 집합, HTTP 요청 수, 수신된 TCP 바이트, 로드된 바이너리 수, 컨텍스트 전환 수, DWM 비디오 메모리 사용량, GPU 사용률(%), 페인트 수, JavaScript 가비지 수집의 CPU 시간, JavaScript 구문 분석의 CPU 시간, 평균 DWM 업데이트 간격, 최대 총 작업 집합, 힙 할당 수, 힙 할당 크기, 대기 중인 힙 할당 수, 대기 중인 힙 할당 크기, 레이아웃 하위 시스템의 CPU 시간, 서식 하위 시스템의 CPU 시간, 렌더링 하위 시스템의 CPU 시간, HTML 파서 하위 시스템의 CPU 시간, 유휴 CPU 시간, 스레드 수 등
Windows 이벤트 추적 인프라
평가 요소는 Windows 이벤트 추적 인프라(ETW)와 VMMap을 사용하여 수집됩니다. ETW는 Windows 이벤트 로그 등 다양한 Windows 구성 요소와 타사 응용 프로그램에서 사용되는 Windows 전반의 이벤트 로깅 시스템입니다. ETW 로깅 API는 매우 낮은 레벨에서 작동하고 오버헤드도 낮아 성능 테스트에 매우 중요합니다.
WPT에 포함된 추적 뷰어인 xperfview.exe는 커널, CPU, GPU, I/O, 네트워킹 및 기타 이벤트를 서로 관련시키고 겹쳐 표시할 수 있는 강력한 시각화 도구입니다. WPT는 스택 검색도 지원합니다. 스택 검색으로 프로그램의 호출 스택이 일정 시간 간격으로 포착되고 추적 정보의 일부로 이 스택이 저장됩니다. WPT는 ETW 이벤트를 스택과 상호 관련시킴으로써 수행 중이던 작업의 내용뿐만 아니라 이 작업과 관련된 호출 스택 및 이 작업에 소요된 시간을 10마이크로초 단위로 표시합니다. 스택 검색은 ETW 이벤트를 사용하지 않는 프로세스를 포함하여 모든 프로세스에 사용할 수 있습니다. 스택 검색의 단점은 스택 디코드를 위해 기호 디버깅이 필요하고 앨리어싱에 민감하다는 것입니다.
시나리오 테스트
마지막 단계로 실제 테스트를 진행합니다. 테스트는 설정, 테스트 및 오류와 정리의 3단계로 세분할 수 있습니다. 이해를 돕기 위해 아래에 전체 프로세스의 흐름도를 나타내었습니다.
설정
프로세스는 사용자가 랩 웹 사이트 또는 자동화 프레임워크를 통해 실행을 요청하면서 시작됩니다. 실행은 대기 중인 다른 실행과 함께 우선순위 대기열에 놓입니다. 테스트 클라이언트가 사용 가능해지면 이 클라이언트가 대기열을 확인하여 수행할 수 있는 가장 높은 우선순위의 작업을 시작합니다. 테스트 클라이언트는 우선 지정된 테스트 OS를 설치합니다. IE 성능 랩에서는 Vista, Windows 7 및 Windows 8에서의 테스트를 지원합니다. 테스트 클라이언트는 실행할 때마다 테스트 OS를 새롭게 설치하여 시스템이 항상 알려진 양호한 상태에서 시작되도록 합니다.
테스트 OS가 설치되면 클라이언트가 WPT, VMMap 및 테스트 도구를 구성합니다. 실행 과정에서 홈 페이지, 제안 사이트의 수, InPrivate 브라우징 등 다양한 IE 설정도 지정됩니다. 이 시점에서 타사 소프트웨어도 설치 및 구성됩니다.
테스트 전의 마지막 단계는 테스트 클라이언트가 유휴 상태인지를 확인하여 테스트의 간섭 영향을 최소화하는 것입니다. Windows에서는 유휴 작업을 특정한 개념으로 정의합니다. 유휴 작업은 Windows와 다른 개발자들이 중요하지 않은 작업을 사용자의 리소스 경합이 없는 이후 시간에 실행되도록 예약하는 한 방법입니다. OS 유휴 작업에는 OS 버전과 구성 서비스에 따라 프리페치 또는 수퍼페치, 디스크 조각 모음, 검색 인덱스 업데이트 등이 포함됩니다. 테스트 과정에서 유휴 작업이 수행되지 않도록 하기 위해 유휴 작업 대기열이 지워집니다. 이와 함께, Windows Defender의 작동이 일시 중지되고 테스트 도구의 로그 위치가 Windows 인덱싱 서비스에서 제외된 것으로 표시되어 테스트 실행 중 로그 및 추적 파일로 인해 인덱서가 시작되는 일이 없도록 합니다. 공급자가 추가될수록 관찰자 효과가 증가하기 때문에 테스트를 여러 단계로 실행하여 필요한 공급자의 수를 최소화합니다. 첫 번째 단계는 항상 준비 단계입니다. 준비 단계에서는 브라우저 바이너리를 '예열'된 상태로 유지하고 WinINET 캐시에서 캐싱 가능한 최대 페이지 콘텐츠가 준비되도록 합니다. 이후 단계에서는 각각 스택 검색, 메모리 추적, 그리고 I/O 및 레지스트리 추적과 같은 특정한 형태의 계측에 중점을 둡니다.
오류 및 정리
테스트 중 언제라도 브라우저가 충돌하면 이 테스트 단계는 실패한 것으로 간주되고 실행이 다음 테스트 단계로 넘어갑니다. 테스트 중 언제라도 Windows가 충돌하면 현재 상태를 보장할 수 없기 때문에 컴퓨터가 다시 부팅된 후 OS가 다시 설치됩니다. 또한 재시도 횟수가 임계값을 초과하면 불안정한 테스트를 무한정 시도하지 않도록 전체 실행이 실패한 것으로 간주되고 시스템이 다른 실행으로 넘어갑니다.
모든 테스트 사례가 완료되면 테스트 클라이언트가 분석에 이용할 로그와 추적 정보를 업로드합니다. 그런 다음 테스트 클라이언트는 유휴 상태로 복귀하여 새로운 실행에 대해 폴링을 시작합니다.
결과 조사
각 평가 요소는 그 변화 추이를 추적합니다. 랩에서는 각 테스트 사례를 최소 10회 이상 실행하고 두 대 이상의 시스템에서 실행을 반복하여 샘플 모집단을 구성합니다. 통계 도구를 사용하여 특이성이 없는 결과는 자동으로 조사 대상으로 분류됩니다. 분산의 변화도 회귀로 취급됩니다. 사용자는 매우 다양한 환경에서 매우 다양한 하드웨어를 이용하여 IE와 상호 작용하기 때문에 우리의 목표 중 하나는 항상 부드럽고 예측 가능한 경험을 보장하는 것입니다.
자동 분석을 실시하는 외에도 중요도 분류 팀은 매일 입수되는 결과를 조사하여 중요한 추세나 동작을 찾아냅니다. 많은 통계 도구는 정규 분포 외에도 모든 샘플이 독립적이라고 가정하기 때문에 수작업에 의한 조사를 빼놓을 수 없습니다. 랩에서 수행하는 측정은 이 두 가지 가정 모두 절대적이라고 할 수 없습니다. IE의 일부 활동은 OS의 타이머에 의해 구동되기 때문에 타이머 주기를 기준으로 페이지 로드가 시작되는 시기에 따라 결과가 달라질 수 있습니다. 타이머 인터럽트 바로 전이나 후에 시작되는 페이지 로드는 더 적거나 더 많은 작업을 수행할 수 있습니다. IE가 페이지 로드 프로세스의 여러 시점에서 인터럽트를 처리해야 하기 때문입니다. 이러한 간섭은 물결 효과를 나타내어 이봉 분포(bimodal distribution)를 만듭니다. 그뿐 아니라, 반복 실행 사이에서 시스템을 소거하지 않고 반복적 시도를 이용하기 때문에 다음 시도가 이전 시도의 영향을 받게 됩니다. 다음은 변화 추이 비교를 위한 Bing 지도의 경과 시간 그래프 샘플입니다.
빨간색 선은 각 테스트 실행의 중앙값이고 회색 막대는 범위를 나타냅니다. 테스트 실행 위로 마우스를 가져가면 평가 요소에 대한 반복 실행(파란색)뿐만 아니라 최소값, 중앙값, 최대값과 함께 이전 테스트 실행과의 절대 및 상대적 차이에 대한 정확한 값을 제공하는 도구 설명이 표시됩니다. 이 이미지에 보이는 도구 설명에는 테스트 중인 빌드 등의 추가적인 배경 정보가 표시되고, 빌드의 변경을 확인하기 위한 소스 제어 시스템으로 바로 연결되는 링크도 제공됩니다.
IE 팀은 자동 분석 결과와 수동 조사 결과를 종합하여 성능 최적화를 위한 신뢰할 수 있고 수행 가능한 데이터를 얻습니다.
타사 소프트웨어 테스트
많은 타사 응용 프로그램은 Trident, 네트워크 스택 및 기타 IE 구성 요소에 의존합니다. BHO 및 도구 설명과 같은 확장 기능은 IE 컨텍스트 내에서 로드되고, 보안 소프트웨어와 같은 기타 응용 프로그램은 IE 구성 요소 사이에 삽입될 수 있습니다. 이러한 응용 프로그램은 IE 스택의 일부가 되어 성능을 저하시킬 수 있는데, 성능 랩에서는 제어된 환경에서 실제 콘텐츠 브라우징에 미치는 타사 소프트웨어의 영향을 측정할 수 있습니다. 사용자는 일반적으로 자신의 브라우징 경험에 미치는 주요 소프트웨어의 영향을 수치적으로 확인할 수 없기 때문에 이러한 연구는 IE와 에코시스템에 중요합니다.
타사 소프트웨어의 영향을 테스트할 때는 타사 소프트웨어가 설치된 상태의 실행 결과와 IE만 설치된 기본적 상태의 실행 결과를 비교하여 소프트웨어의 영향을 확인합니다. 특히 시작 시간과 탐색 시간의 두 가지 평가 요소 측정에 중점을 둡니다. 시작 시간은 브라우저를 실행하여 URL로 이동하는 시간을 측정하고, 탐색 시간은 브라우저가 이미 실행되었을 때 URL로 이동하는 시간을 측정합니다. 시작 시간에는 타사 응용 프로그램이 해당 IE 확장 기능을 로드하는 시간도 포함됩니다.
캐싱 콘텐츠를 사용하면 측정의 반복성을 유지할 수 있습니다. 또한, 캐싱 사이트를 측정함으로써 성능 저하가 사이트에 존재하는 차이가 아니라 타사 소프트웨어에 의해 발생한 것임을 확실히 알 수 있습니다. 타사 소프트웨어의 영향을 측정할 때는 항상 인터넷 직접 연결의 시작 및 이동을 테스트하여 결과의 유효성을 검증함으로써 차이가 생긴 원인이 테스트 환경에 있지 않다는 것을 확인합니다.
많은 타사 응용 프로그램은 페이지 이동 중 작업 처리를 클라우드 서비스에 위임하는데, 작업의 병렬 처리와 클라우드 서비스의 이용은 성능 개선을 위한 훌륭한 방법이긴 하지만 일부 응용 프로그램은 네트워크로부터 동기식으로 결과를 기다리기 때문에 이동이 차단되는 문제를 야기합니다. 엄격한 방화벽, WAN 연결 및 오프라인 시나리오 등은 사용자의 입장에서 이러한 패턴 때문에 실제로 성능이 저하되는 상황을 만들곤 합니다. 타사 소프트웨어는 IE나 사용자의 작업 요청을 절대 동기식으로 처리하면 안 되며 UI와 DOM 업데이트를 일괄적으로 처리하여 작업 중단을 최소화해야 합니다.
사용자를 위한 빠른 브라우저 구축
실제 사용 환경에서의 브라우저 성능이 중요합니다. 대규모 성능 테스트를 위해서는 많은 투자와 전담 직원의 배정이 필요하지만 이로부터 얻는 결과는 그만한 가치가 충분히 있습니다. Internet Explorer 성능 랩에서 수집되는 정보는 우리가 브라우저 성능과 기본적 PC 하드웨어를 이해하는 데 도움을 주며, 사용자에게 빠르고 부드럽게 반응하는 웹 경험을 선사할 수 있도록 개발하는 데 매우 중요한 역할을 합니다.
- Internet Explorer 성능 팀, Matt Kotsenas, Jatinder Mann, Jason Weber
Comments
- Anonymous
February 28, 2012
Wow!! InternetExplorer is very goodI want to use InternetExplorer10 and Windows 8 NOW!!!!!!!!!!!