라즈베리 파이에서 웹 브라우징의 병목 현상은 어디에 있습니까?

Raspbian“wheezy”가 포함 된 모델 B 512MB Pi에서 Midori, Chromium 및 Iceweasel을 사용해 보았습니다. 웹 페이지가 커지면 1GHz로 오버 클럭 한 후에도 로딩 속도가 느려집니다. CPU가 1GHz 인 안드로이드 폰에서는 웹 페이지 로딩이 훨씬 빠릅니다.

내가 알고 싶은 것은 Pi의 병목 현상이 어디에 있습니까? CPU입니까, RAM 크기입니까, 가속되지 않은 X 서버입니까? 브라우저가 GPU 속도를 높이기 위해 GPU를 직접 사용할 수 있습니까?

Raspberry Pi의 상당히 약한 ARM11 CPU와 가속되지 않은 X 서버의 조합입니다. GPU에 의해 가속되지 않기 때문에 CPU는 모든 렌더링을 수행해야합니다. Pi의 ARM11 코어와 같은 것으로 이미 약한 CPU에 많은 부담이 있습니다.

일명, htopPi의 Midori가 Facebook과 같은 무거운 웹 사이트를로드하는 동안 X 프로세스가 CPU의 최대 25 %를 차지하는 것을 보았습니다.

안드로이드 폰의 칩과 파이의 칩 (오버 클럭킹)을 비교하는 것은 실제로 공평하지 않습니다. 휴대 전화의 1GHz 칩은 아마도 ARMv7 버전의 아키텍처를 사용하는 Cortex-A8 또는 A9와 같은 것일 수 있습니다. 따라서 ARMv6을 사용하는 ARM11보다 클록주기 당 성능이 더 높습니다.

이것은 이미 정답 IMO이며, 내가 제안하는 것은 큰 차이를 만들지 않지만 알고 있으면 유용 할 수 있습니다.

브라우저를 실행하기 만하면 데스크톱 환경도 실행할 필요가 없습니다. 다음과 같은 파일을 작성하십시오 $HOME/.xinitrc.

#!/bin/sh

midori

.xinitrc가 이미 존재하면 임시로 옮기거나 다른 것을 주석 처리하십시오. 자, startx(이미 포함되어 있지 않아야합니다. GUI를 실행하지 않고 콘솔에서 수행하십시오). Voila, 브라우저 만 있고 데스크탑은 없습니다.

브라우저가 방 안에있는 코끼리이고 Xorg 서버 자체 (실행중인)가 기본 lxde (현재 실행되지 않는) 보다 크지 만 메모리를 절약 할 수 있습니다 . 스왑을 사용하기 위해 RAM에 너무 많은로드가 있으면 성능에 영향을줍니다. 위의 미도리 + 베어 X는 free다음 에 따라 <100MB 상주를 사용합니다 .

             total       used       free     shared    buffers     cached
Mem:        448708     242604     206104          0      82660     105156
-/+ buffers/cache:      54788     393920
Swap:       102396          0     102396

448708-393920 = 54788/1024 = 53.5MB

4 개의 탭이 열려 있습니다. 다시 한 번 살펴보면 RAM이 거의 가득 차면 성능 문제입니다. 이 램이 경우에도 스왑의 비트를 사용하는 것이 정상입니다 참고 하지 교환 물건을 낮은 우선 순위입니다 - 그래서 그것에 대해 걱정하지 마십시오 전체.

성능 측면 에서 고려해야 할 사항은 버퍼와 캐시의 중요성입니다 . 나는 이것을 총체적으로 포함시키지 않았으며 실제로 커밋 된 메모리 (약 두 배) 이상임을 알았습니다. 정상입니다. 커밋 된 것들로 메모리를 채우면 시스템은 더 적은 캐시를 사용하거나 스왑으로 전송합니다. 어느 쪽이든 캐시 는 중요 하기 때문에 성능이 저하 될 것입니다 (크기가 현명하지 않거나 불변의 크기는 아니므로 커밋 된 mem 통계의 일부가 아닙니다).

다시 말해, 최선을 다하면 커밋 된 램 이 파이 에서 사용할 수있는 것의 75 %를 넘지 않도록 하고 싶을 것입니다. LXDE를 사용하고 다른 것을 열기 시작하면 빠르게 접근 할 수 있습니다.

면책 조항 : 다음은 모호한 효과가있는 실험 기능 사용에 대해 설명합니다. 도입 된 회귀 및 실제 성능 향상을 테스트해야합니다.

아래 의 Chrome / Chromium 플래그chrome://flags 를 사용하여 (겉보기) 브라우징 성능을 향상시킬 수 있습니다. 성능과 관련된 플래그 중 일부를 설명 하는 기사 가 있습니다 . 나는 여기에 몇 가지를 수집하려고합니다.

"Overrrite Software Rendering List"를 활성화하여 GPU 가속 을 강제 하면 드라이버가 허용 목록에없는 경우에도 가능한 아티팩트 비용으로 렌더링에 GPU를 사용합니다. 그래도 이것이 Pi의 GPU와 얼마나 잘 작동하는지 모르겠습니다.

모든 페이지의 GPU 합성 은 GPU를 사용하여 모든 레이어를 스크롤합니다. 따라서 GPU 가속 레이어가없는 페이지에서 스크롤 성능이 향상됩니다.

타일 ​​방식으로 창을 새로 고치는 것이 또 다른 힌트입니다. 마지막 타일이 끝나기를 기다리는 대신 준비가 되 자마자 타일을 렌더링하고 각각을 표시합니다. 실제로 오버 헤드가 발생하여 렌더링 시간이 길어 지지만 내용이 더 빨리 나타납니다.

별도의 스레드 에서 렌더링하면 렌더링이 비동기 적으로 수행되고 인터페이스의 응답 성이 유지됩니다. 페이지가 여전히 렌더링되는 동안 스크롤 할 수 있습니다.

GPU 비활성화 VSync 는 모니터가 아직로드했는지 여부에 관계없이 렌더링 된 내용을 업데이트합니다. 일관성없는 프리젠 테이션 비용으로 프레임 속도가 향상됩니다.

스위치를 활성화 / 비활성화 한 후 설정을 적용하려면 Chrome / Chromium을 다시 시작해야합니다. 플래그 페이지 하단에있는 버튼을 사용하면됩니다.

더 나아가서 커맨드 라인 스위치를 사용하여 Chrome / Chromium을 최적화 할 수 있습니다. 전체 목록은 Chromium 명령 행 스위치 목록을 참조하십시오 .

--default-tile-width그리고 --default-tile-height각 페이지의 초기 렌더링 속도를 높이기 위해 화면 크기의 분수에 맞게 설정할 수 있습니다.