Где узкое место для просмотра веб-страниц на малиновом пи?

На модели B 512 МБ Pi с Raspbian «wheezy», я попробовал Midori, Chromium и Iceweasel. Когда веб-страница становится больше, загрузка идет медленно, даже после того, как я разогнал ее до 1 ГГц. На Android-телефоне с тактовой частотой 1 ГГц загрузка веб-страницы выглядит намного быстрее.

Что я хочу знать, где узкое место в Пи? Является ли это процессором, размером оперативной памяти или неуправляемым X-сервером? Возможно ли, чтобы браузер использовал графический процессор напрямую, чтобы ускорить его?

23 голоса | спросил hello.wjx 24 FebruaryEurope/MoscowbSun, 24 Feb 2013 07:42:22 +0400000000amSun, 24 Feb 2013 07:42:22 +040013 2013, 07:42:22

3 ответа


15

Это комбинация довольно слабого процессора ARM11 Raspberry Pi и неопущенного X-сервера. Поскольку он не ускоряется GPU, CPU должен выполнять весь рендеринг; на чем-то вроде ядра ARM11 в Pi, это накладывает много дополнительного напряжения на уже слабый процессор.

Анекдотически, наблюдая htop, в то время как Midori на Pi загружает тяжелый веб-сайт, такой как Facebook, я видел, что процесс X занимает до 25% от CPU.

Совсем нечестно сравнивать чип на вашем телефоне Android с чипом (даже разогнанным) в Pi. Чип на 1 ГГц на вашем телефоне, вероятно, похож на Cortex-A8 или A9, которые используют ARMv7-версию архитектуры; таким образом, они имеют более высокую производительность за такт, чем ARM11, который использует ARMv6.

ответил nc4pk 25 FebruaryEurope/MoscowbMon, 25 Feb 2013 00:32:50 +0400000000amMon, 25 Feb 2013 00:32:50 +040013 2013, 00:32:50
14

Это уже правильный ответ IMO, и то, что я предлагаю, вероятно, не будет иметь большого значения, но это может быть полезно знать.

Если все, что вы хотите сделать, это запустить браузер, вам также не нужно запускать среду рабочего стола. Создайте файл, который выглядит как $HOME/.xinitrc:

#!/bin/sh

midori

Если .xinitrc уже существует, временно переместите его или закомментируйте что-нибудь еще. Теперь startx (очевидно, вы не должны быть в нем уже - сделайте это с консоли без запуска графического интерфейса). Voila, у вас есть только браузер, нет рабочего стола.

Это экономит небольшой бит памяти, хотя браузер на сегодняшний день является слоном в комнате, а сам сервер Xorg (который работает) больше, чем basic lxde (который теперь не является Бег). Если вы столько загрузили в ОЗУ, что используете swap, это повлияет на производительность. Вышеуказанный мидори + голый X использует <100 МБ резидент в соответствии с free:

             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,5 МБ

Откроется 4 вкладки. Опять же, если вы посмотрите на них и увидите, что ваша операционная система находится в полном объеме, это проблема производительности. Обратите внимание, что нормально использовать бит свопинга, даже если ram not заполнен, поэтому не беспокойтесь об этом - этот обменный материал имеет низкий приоритет.

Что-то, о чем нужно подумать, с точки зрения производительности, значение буферов и кешей . Я не включал их в общую сумму и замечаю, что это на самом деле больше, чем зафиксированная память (примерно в два раза больше). Это нормально. Если вы заполняете память совершенными вещами, система будет использовать меньше кеша и /или передавать ее для обмена. В любом случае это будет ухудшение производительности, потому что кеш важен (он просто не является жизненно важным или неизменным по размеру, поэтому не является частью зафиксированного mem stat).

Другими словами, оптимально вы хотите, чтобы ваш преданный баран был не более 75% доступного на пи и, возможно, меньше этого. Если вы используете LXDE и начинаете открывать другие вещи, вы можете быстро приступить к этому.

ответил goldilocks 25 FebruaryEurope/MoscowbMon, 25 Feb 2013 18:24:56 +0400000000pmMon, 25 Feb 2013 18:24:56 +040013 2013, 18:24:56
5
  

Отказ от ответственности . Ниже описывается использование экспериментальных функций с сомнительными эффектами. Обязательно проверяйте введенные регрессии и фактическую прирост производительности.

Вы можете попробовать некоторые из флагов Google Chrome /Chromium под chrome://flags, чтобы улучшить (видимую) производительность просмотра. Существует статья, объясняющая некоторые флаги, относящиеся к производительности . Я попытаюсь собрать некоторые из них здесь:

Принудительное ускорение GPU , включив «Overrrite Software Rendering List», будет использовать графический процессор для рендеринга за счет возможных артефактов, даже если драйвер не включен в белый список. Я не знаю, насколько хорошо это работает с графическим процессором Pi.

Компиляция графического процессора на всех страницах будет использовать графический процессор для прокрутки всех слоев. Таким образом, производительность прокрутки должна улучшаться на страницах без GPU-ускоренных слоев.

Обновить окно tilewise - это еще один намек. Он будет отображать плитки и отображать каждый, как только он будет готов, а не ждать окончания последнего. В действительности рендеринг займет больше времени из-за введенных служебных данных, но контент будет отображаться быстрее.

Рендеринг в отдельном потоке будет выполнять рендеринг асинхронно и поддерживать взаимодействие интерфейса. Вы можете прокручивать, пока страница все еще отображается.

Отключить GPU VSync будет обновлять отображаемое содержимое независимо от того, загрузил ли монитор их еще. Это улучшает частоту кадров за счет несогласованного представления.

После включения /отключения любых переключателей вам потребуется перезапустить Chrome /Chromium для установки. Кнопка внизу страницы flags может сделать это для вас.

Идя дальше, переключатели командной строки могут использоваться для оптимизации Chrome /Chromium. Полный список можно найти в списке переключателей командной строки Chromium .

--default-tile-width и --default-tile-height может быть настроен так, чтобы соответствовать части размера экрана, чтобы ускорить первоначальный рендеринг каждой страницы.

ответил Bengt 27 FebruaryEurope/MoscowbWed, 27 Feb 2013 01:49:18 +0400000000amWed, 27 Feb 2013 01:49:18 +040013 2013, 01:49:18

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132