이전글
파이어폭스(Mozilla Firefox) 렌더링 속도 끌어올리기의 후속 글입니다.
파이어폭스의 멀티-프로세스 적용작업이 긴 테스트를 끝내고 버전 51부터 기본적으로 활성화된다는 걸로 알고 있었습니다. 헌데, 엊그제 릴리즈된 버전 51을 설치해도 멀티-프로세스 방식이 활성화되질 않더군요. 그래서, 수동으로 적용할 수 있는 방법을 찾아봤습니다.
1. 파이어폭스 멀티-프로세스 적용 스케쥴
멀티-프로세스 기능을 모질라 재단 쪽에선 Electrolysis (전기분해??) 혹은 줄여서 e10s 라고 부르더군요. 이름이 너무 복잡하니 줄여서 e10s로 적겠습니다.
e10s 기능은 2015년 버전 40부터 내부개발을 시작하여, 릴리즈 채널(일반 사용자 대상 배포채널)에선 버전 48부터 일부 사용자를 대상으로 이 기능을 사용할 수 있도록 테스트를 시작했습니다. 왜 일부 사용자만 대상으로 했냐면 브라우저 플러그인 가운데 e10s와 호환되지 않는 게 많습니다. 그래서, 정상작동이 확인된 일부 플러그인만을 가지고 화이트리스트를 만들었고, 이 화이트리스트에 포함된 플러그인만 사용하는 사용자를 대상으로 e10s 기능을 사용할 수 있도록 했습니다.
아마 우리나라 사용자들은 예외 없이 e10s 기능이 기본적으로 꺼져있을 겁니다. 인터넷 뱅킹용으로 깔린 플러그인 대부분이 화이트리스트에 오르지 못했을 걸로 추정됩니다.
이후 49, 50 버전 적용 대상을 차츰차츰 늘려나갔고, 버전 51부터 기본적으로 e10s가 활성화된다고 알고 있었습니다. 헌데, 엊그제 올라온 51 버전을 설치해보니 여전히 e10s가 비활성화 상태입니다.
2. e10s 적용여부 확인
파이어폭스의 주소입력란에 about:support를 입력하면 아래 화면이 나타납니다.
Multiprocess Windows 항목이 0/1 (Disabled by accessibility tools) 라고 나타나 있습니다. 1은 전체창 프로세스의 갯수, 0은 그 가운데 e10s 기능이 켜진 창의 갯수를 의미합니다. 따라서, 이 값은 e10s가 적용되지 않고 있다는 뜻이고, 설명으로 액세시빌리티 툴에 의해 비활성화됐다고 적혀 있습니다.
만약, e10s 가 활성화된 상태라면 저 숫자가 1/1 이상의 값으로 표시되어야 합니다.
3. e10s 활성화 (opt-in)
사용자 옵션에 의해 e10s 사용여부를 지정할 수 있습니다. 주소입력란에 about:config를 입력하고, 검색란에 'browser.tabs.remote.autostart' 중 일부를 입력하여 이 항목을 찾습니다.
이 항목의 값을 true로 바꿔준 후, 파이어폭스를 재시작합니다. 그 후 앞서 언급한 about:support 페이지에서 e10s가 적용되었는지 확인합니다.
저는 이 옵션을 적용해도 e10s가 적용되지 않는 것으로 나옵니다. 저처럼 액세시빌리티 툴에 의해 비활성화된 상태로 표시되는 분들은 대부분 동일한 결과일 것으로 예상합니다.
4. e10s 강제적용
about:config 화면에서 새 값을 하나 만듭니다. 유형은 Boolean, 이름은 'browser.tabs.remote.force-enable', 값은 true로 지정합니다.
원래 없는 값이라 새로 입력하는 것이고, 잘못 입력했거나 오동작하는 경우엔 이 값을 찾아서 리셋시키고 브라우저를 재시작하면 해당 값이 삭제됩니다.
액세시빌리티 툴에 의해 e10s 기능이 꺼진 상태였다가, e10s를 강제로 켠 후에 호환성 문제로 오류가 발생 수 있습니다. 이럴 땐, about:config 페이지에서 accessibility.force_disabled 항목을 찾아서 값을 1로 지정합니다. 해당 기능을 아예 꺼버리는 옵션인데, 이 옵션을 통해 e10s와의 호환성 문제를 해결할 수도 있습니다.
이 값을 새로 입력하고 나서 브라우저 재시작. 그리고, about:support 페이지를 다시 확인해 봅니다.
이제서야 사용자에 의해 활성화됐다고 나옵니다. 그럼, 작업 관리자에서 실제로 e10s 적용되어 있는지 확인해 봅시다.
윗 부분의 UI를 담당하는 메인 프로세스(메모리 169.4MB 사용중)와 아랫 부분에 백그라운드 작업을 담당하는 워커 프로세스(메모리 88.8MB 사용중)가 확인됩니다.
5. e10s 사용의 장점
예전처럼 e10s를 사용하지 못하는 구조에선 부하가 걸리거나, 응답이 느린 웹서버와의 작업 중엔 멈칫 멈칫 순간적으로 반응이 멈추는 것을 경험할 수 있습니다. 심각할 경우 아래 화면처럼 '응답 없음'이 뜨기도 하죠.
또, 부하가 심하게 걸리는 연산작업은 문제가 생긴 것으로 판단하고, 취소할 것인지 묻기도 합니다.
e10s를 사용하게 되면 내부작업은 워커 프로세스에서 별도로 처리하기 때문에 화면에 보이는 창을 관리는 UI 프로세스가 멈추는 일이 거의 없어집니다. 사용자 입장에선 한결 부드러운 작동상태를 체험하게 되는거죠.
파이어폭스에 e10s를 적용하게 되면 크롬(Google Chrome)에 버금가는 반응성을 확인할 수 있습니다.
6. 실제 빨리지나?
그렇진 않습니다. 브라우저의 물리적인 성능엔 변함이 없으나, 응답성이 개선되어 사용자가 체감하는 성능만 올라갑니다. 작업 중간 중간, 멈칫하던 블록(block)상태가 사라지기 때문에 작업이 종료되는 시점이 약간 빨라지긴 합니다만, 웹브라우저 자체의 연산성능이 크게 나아지진 않습니다.
아래는 확인을 위해 돌려본 벤치마크 결과.
e10s 적용 전후, 4319 -> 4322로 차이가 없습니다.
Basemark 3.0의 e10s 적용결과는 205 ~ 215점 사이더군요.
비교를 위해 크롬도 돌려봤습니다.
크롬의 베이스마크 결과는 WebGL 2.0 테스트가 빠진 것이라 직접 비교는 어렵고, 피스키퍼에선 약간 떨어지는 점수이나 체감하는 성능은 아직은 크롬이 약간 빠르게 느껴집니다. 파이어폭스가 크롬과 견줄 수 있는 수준까지 올라왔다는 것에 만족합니다.
파이어폭스도 크롬처럼 워커 프로세스를 더 세밀하게 여러 개로 나누어버리면, 성능면에선 더 나은 결과가 있을 것 같은데, 아직은 그런 구조가 아니네요.
'컴퓨팅 > 소프트웨어' 카테고리의 다른 글
| Windows 10 1803 RTM 빌드 Slow Ring 프리뷰 채널 배포 시작 (0) | 2018.03.31 |
|---|---|
| SMBv1 프로토콜에서 새로운 보안 취약점(SMBLoris) 발견 및 해결책 (0) | 2017.08.01 |
| 웹 브라우저, 파이어폭스 렌더링 속도 끌어올리기 2/2 (8) | 2016.11.14 |
| 웹 브라우저, 파이어폭스 렌더링 속도 끌어올리기 1/2 (0) | 2016.11.13 |
| Windows 10 KB3189866, KB3185614 업데이트 오류 해결 (8) | 2016.09.14 |