Dov'è il collo di bottiglia della velocità di navigazione web su Raspberry Pi?

Su un modello B da 512 MB Pi con Raspbian "wheezy", ho provato Midori, Chromium e Iceweasel. Quando la pagina Web diventa più grande, il caricamento è lento, anche dopo che l'ho overcloccato a 1 GHz. Su un telefono Android con una CPU da 1 GHz, il caricamento della pagina Web sembra molto più veloce.

Quello che voglio sapere è, dov'è il collo di bottiglia nel Pi? È la CPU, la dimensione della RAM o il server X non accelerato? È possibile per il browser utilizzare direttamente la GPU per accelerarla?

È una combinazione della CPU ARM11 piuttosto debole del Raspberry Pi e del server X non accelerato. Poiché non è accelerato dalla GPU, la CPU deve eseguire tutto il rendering; su qualcosa come il core ARM11 nel Pi, questo mette a dura prova una CPU già debole.

Aneddoticamente, mentre guardavo htopMidori sul Pi caricare un sito Web pesante come Facebook, ho visto il processo X occupare fino al 25% della CPU.

Non è davvero giusto confrontare il chip nel tuo telefono Android con il chip (anche overcloccato) nel Pi. Il chip da 1 GHz nel tuo telefono è probabilmente qualcosa come Cortex-A8 o A9, che utilizza la versione ARMv7 dell'architettura; quindi, sono prestazioni più elevate per ciclo di clock rispetto a ARM11, che utilizza ARMv6.

Questa è già la risposta corretta IMO, e ciò che sto suggerendo probabilmente non farà molta differenza, ma potrebbe essere utile saperlo.

Se tutto ciò che vuoi fare è eseguire il browser, non è necessario eseguire anche un ambiente desktop. Crea un file simile al seguente $HOME/.xinitrc:

#!/bin/sh

midori

Se .xinitrc esiste già, spostalo temporaneamente o commenta qualsiasi altra cosa. Ora, startx(ovviamente, non dovresti esserci già - fallo dalla console senza la GUI in esecuzione). Voilà, hai solo il browser, nessun desktop.

Ciò consente di risparmiare un po 'di memoria, anche se il browser è di gran lunga l'elefante nella stanza e il server Xorg stesso (che è in esecuzione) è più grande di un lxde di base (che ora non è in esecuzione). Se hai caricato così tanto nella RAM che stai utilizzando lo swap, ciò avrà un impatto sulle prestazioni. Il midori sopra + X nudo utilizza <100 MB residenti secondo 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 MB

Questo è con 4 schede aperte. Ancora una volta, se li guardi e vedi che la tua RAM è quasi piena, questo è un problema di prestazioni. Nota che è normale usare un po 'di swap anche se il ram non è pieno, quindi non ti preoccupare, quella roba scambiata ha una priorità bassa.

Qualcosa di più a cui pensare, per quanto riguarda le prestazioni, è il significato di buffer e cache . Non li ho inclusi nel totale e noto che in realtà è più della memoria impegnata (circa il doppio). È normale Se riempi la memoria con cose impegnate, il sistema utilizzerà solo meno cache e / o trasferirà per scambiare. Ad ogni modo, questo sarà un peggioramento delle prestazioni perché la cache è importante (non è solo vitale o immutabile per quanto riguarda le dimensioni, quindi non fa parte della statistica mem impegnata).

In altre parole, vuoi che il tuo RAM impegnato non sia più del 75% di ciò che è disponibile sul pi e forse meno di quello. Se usi LXDE e inizi ad aprire altre cose, potresti iniziare ad avvicinarti rapidamente.

Disclaimer : Di seguito viene descritto l'utilizzo di funzionalità sperimentali con effetti dubbi. Assicurati di testare le regressioni introdotte e gli effettivi miglioramenti delle prestazioni.

Potresti provare alcune delle bandiere di Google Chrome / Chromium sotto sotto chrome://flagsper migliorare le prestazioni (apparenti) di navigazione. C'è un articolo che spiega alcune delle bandiere rilevanti per le prestazioni . Proverò a collezionarne alcuni qui:

Forzare l'accelerazione della GPU abilitando "Sovrascrivi elenco rendering software" utilizzerà la GPU per il rendering a costo di possibili artefatti, anche se il driver non è nella lista bianca. Tuttavia, non so quanto funzioni bene con la GPU Pi.

La composizione GPU su tutte le pagine utilizzerà la GPU per scorrere tutti i livelli. Quindi le prestazioni di scorrimento dovrebbero migliorare sulle pagine senza livelli con accelerazione GPU.

Un altro suggerimento sarebbe di aggiornare la finestra a sezioni . Renderà i riquadri e li visualizzerà non appena sarà pronto, invece di aspettare che l'ultimo finisca. In effetti il ​​rendering richiederà più tempo a causa del sovraccarico introdotto, ma il contenuto apparirà più velocemente.

Il rendering in thread separato eseguirà il rendering in modo asincrono e manterrà l'interfaccia reattiva. È possibile scorrere mentre la pagina è ancora in rendering.

Disabilita GPU VSync aggiornerà i contenuti renderizzati indipendentemente dal fatto che il monitor li abbia ancora caricati. Ciò migliora la frequenza dei fotogrammi a scapito di una presentazione incoerente.

Dopo aver abilitato / disabilitato tutti gli switch, dovrai riavviare Chrome / Chromium per applicare l'impostazione. Il pulsante nella parte inferiore della pagina delle bandiere può farlo per te.

Andando ancora oltre, le opzioni della riga di comando potrebbero essere utilizzate per ottimizzare Chrome / Chromium. Consulta l' elenco delle opzioni della riga di comando di Chromium per un elenco completo.

--default-tile-widthe --default-tile-heightpotrebbe essere impostato in modo che corrisponda a una frazione delle dimensioni dello schermo per accelerare il rendering iniziale di ogni pagina.