HPN #03: i processi interni a Chrome

Di - 30 April 2013 - in
High Performance Networking

Come sicuramente ricorderete, nell’ultima puntata di questa guida abbiamo individuato il nostro problema principale: ridurre il più possibile il tempo di latenza delle nostre applicazioni web per soddisfare la richiesta di rapidità dell’utente. In questa puntata ci addentriamo nei dettagli di come Chrome gestisce le applicazioni web e i processi che influiscono nelle prestazioni.

Architettura a processi multipli

Già nelle puntate precedenti abbiamo evidenziato come l’introduzione di un modello a processi multipli abbia portato grandi vantaggi e importanti implicazioni su come il browser gestisce le richieste. Attualmente Chrome supporta quattro diversi modelli di esecuzione che determinano come viene eseguita l’allocazione dei processi.

Di default Google Chrome utilizza un modello a processi-per-sito, che isola diversi siti l’uno dall’altro, ma raggruppa tutte le istanze di un sito in un singolo processo. Per semplificare le cose, però, assumiamo di avere siti diversi in ogni scheda aperta, di conseguenza un processo per ogni scheda. Dal punto di vista delle prestazioni non ci sono grandi differenze, ma questo contesto ci permette di analizzare le cose più semplicemente.

Processi Google ChromeL’architettura dedica un processo di rendering (render process) ad ogni scheda. Ognuno di questi processi contiene un’istanza del motore di rendering open source WebKit (“HTML Renderer” nell’immagine) per interpretare il codice HTML e restituire il layout della pagina, un’istanza del motore JavaScript V8 e del codice per collegare tra loro queste ed altre componenti.

Ognuno di questi render process viene eseguito all’interno di una sandbox che ha accesso limitato al computer dell’utente, incluso il network. Ciò vuol dire che per avere accesso alle risorse, ogni render process deve comunicare con il processo del browser (kernel), che gestisce la sicurezza e le politiche di accesso di ogni renderer.

Inter-Process Communication (IPC) e caricamento delle risorse multi-processo

Tutte le comunicazioni tra i render process e il kernel process in Chrome avvengono via IPC. In Linux e Mac OS viene utilizzato un socketpair(), che fornisce una via di trasporto per la comunicazione asincrona. Ogni messaggio dal render process viene serializzato e passato ad un I/O thread dedicato, che lo inoltra al kernel process. Alla ricezione, il kernel process fornisce un filtro che permette a Chrome di intercettare le richieste IPC di risorse (per un approfondimento: ResourceMessageFilter) che dovrebbero essere gestite dal network stack, una libreria dedicata principalmente al fetch delle risorse.

Chrome IPCUn vantaggio di questo approccio risiede nel fatto che tutte le richieste di risorse vengono interamente gestite dagli I/O thread e né un’attività generata dall’Interfaccia Utente né gli eventi del network possono interferire tra loro. Il filtro delle risorse, come già detto, agisce nel processo del browser, intercetta i messaggi di richiesta di risorse e li inoltra al ResourceDispatcherHost nel processo del browser stesso.

L’ultima interfaccia citata permette al browser di controllare l’accesso alla rete di ogni renderer e al tempo stesso offre un’efficiente condivisione di risorse:

  • Socket pool e limiti di connessione: il browser è in grado di rinforzare i limiti sul numero di socket aperti per profilo (256), proxy (32), e gruppi {scheme, host, port} (6). C’è da notare che questo sistema permette fino a sei connessioni HTTP e sei HTTPS allo stesso gruppo {host, port}.
  • Riutilizzo dei socket: le connessioni TCP persistenti sono trattenute nel socket pool per un po’ di tempo dopo aver servito la richiesta di abilitazione al riutilizzo della connessione, cosa che permette di evitare l’overhead aggiuntivo del setup DNS, TCP e SSL (se richiesto) imposto ad ogni nuova connessione.
  • Tardo abbinamento dei socket: le richieste sono associate ad una sottostante connessione TCP solo una volta che il socket è in grado di gestire la richiesta stessa, permettendo così una migliore gestione delle priorità (per esempio l’arrivo di una richiesta con priorità maggiore mentre il socket si sta connettendo), una migliore allocazione, così come un meccanismo generale per la pre-connessione TCP e un certo numero di altre ottimizzazioni.
  • Stato della sessione consistente: autenticazione, cookie e dati in cache sono condivisi tra tutti i render process.
  • Ottimizzazioni della connessione e delle risorse globali: il browser è in grado di compiere scelte di stampo generale, tra tutti i render process e le richieste in coda, per esempio conferendo una maggiore priorità alle richieste provenienti dalla scheda in primo piano.
  • Ottimizzazioni previdenti: osservando l’intero traffico, Chrome è in grado di definire modelli di previsione per migliorare le prestazioni.

Se si considera un render process, tutto quel che fa è inviare tramite IPC un messaggio di richiesta di risorse, che viene identificato con un ID unico, e il kernel process del browser gestisce il resto.

Leave a Reply

Pagine: 1 2

Mattia Migliorini Articolo scritto da

Studente di informatica presso l'Università di Padova, web designer, amante di Linux e dell'open source in generale. Membro di Ubuntu e di 2viLUG, da gennaio 2012 è collaboratore di Engeene.

Contatta l'autore

Previous post:

Next post: