Memorizzazione nella cache del bootstrap di Drupal


10

Sono curioso di sapere se qualcuno ha tentato di "memorizzare nella cache" il processo bootstrap in Drupal.

Normalmente, Drupal eseguirà le 7 fasi di bootstrap su ogni richiesta, ma forse su un sistema di produzione distribuito, si potrebbe "eliminare" alcune o tutte queste?

Possibili suggerimenti che ho in mente potrebbero essere

  1. Serializzazione dello stato di bootstrap e inserimento in memcache
  2. Uno script potrebbe generare una patch per bootstrap.inc che codificherà determinate informazioni nel file.
  3. Credo che David Strauss abbia provato a far funzionare un Drupal con bootstrap su libevent.
  4. Altra follia?

Quali tentativi ci sono e quali sono noti per essere (in qualche modo) affidabili?


Questo è in qualche modo collegato alla mia domanda sulla compilazione di Drupal: drupal.stackexchange.com/q/11738/2916
Refineo

Risposte:


12

PHP è un'architettura nulla condivisa. Questo ha i suoi vantaggi e svantaggi.

Uno svantaggio è che non è facile fare qualcosa del genere. Non c'è molto di uno stato che può essere memorizzato da qualche parte.

Ho fatto alcuni test rapidi e dopo aver effettuato l'accesso, il boostrap sembra richiedere circa il 17% circa del tempo totale e oltre il 50% di questo sta effettivamente caricando tutti i file .module e .inc. Non è qualcosa che puoi archiviare in memcache. Inoltre, non sembra importare molto se uso memcache o la cache del database.

Ho cercato di ottenere alcuni risultati quando la cache della pagina era abilitata, ma Xhprof non sembra restituire risultati affidabili allora; il tutto sembra semplicemente essere troppo veloce. Ma anche in questo caso, la parte più importante riguarda l'esecuzione di hook di init / exit e il caricamento dei file. Ho riscontrato un problema interessante lì: sembra che il modulo Utente stia rallentando seriamente la risposta della pagina cache perché innesca il registro a causa del controller di entità nel file .module.

Detto questo, David Strauss ha mostrato alcuni lavori sperimentali a Copenaghen in cui ha creato un'istantanea della memoria dopo l'avvio del bootstrap e poi tornando a quello una volta che la pagina è stata pubblicata. Ha usato Drupal 6 per questo. Dopo aver esaminato i numeri sopra, immagino che i guadagni prestazionali di farlo in Drupal 7 sarebbero un po 'più piccoli. Uno dei motivi è che la connessione al database è caricata in modo pigro (e puoi andare abbastanza lontano nel bootstrap quando usi ad esempio Memcache prima di dover eseguire la prima query) e c'è molto che viene memorizzato nella cache.

Ciò che è veramente brutto in Drupal 7 è il livello di rendering con questi enormi array e infinite ricorsioni e loop. Quello praticamente annulla tutto il lavoro prestazionale svolto in Drupal 7. Vediamo come appare in Drupal 8, se Twig lo rende fondamentale.

Infine, sui vantaggi citati. Un grande vantaggio è che i porri di memoria sono piuttosto irrilevanti perché tutto viene liberato dopo ogni richiesta. Ho visto molte applicazioni Java in cui l'utilizzo della memoria aumenta costantemente e hanno bisogno di riavvii regolari.


4
Mi piace tanto averti sul sito @Berdir;)
Letharion

Alex Bronstein ha menzionato durante lo sprint che è piuttosto lento includere i file tpl.php anche con APC richiede una stat - ma Twig si compila in classi in modo che sarà una vittoria su pagine come nodo + molti commenti. Vedremo.

Immagino che potresti creare un sistema in cui, per le pagine memorizzate nella cache, generi un sacco di regole di riscrittura e inseriscile in .htaccess, accompagnato da pagine html per bypassare completamente PHP. Potrebbe non valere la pena però: IIS, nginx, utenti connessi, ...
Bart,

1
@Bart: hai appena reinventato Boost: drupal.org/project/boost :)
Berdir,

5

No, era David Strauss che stava sperimentando l'evento kargo (ora chiamato Kellner) su https://code.launchpad.net/~fourkitchens/pressflow/6-events, ma dubito che ne sia venuto fuori qualcosa di grave.

Drupal 7 ha già un sacco di bootstrap già memorizzati nella cache, c'è un cache_bootstrapcestino per quello. Puoi incollarlo in memcached.

Puoi esagerare e ridurre il caricamento del codice con lo spostamento di alcuni / molti codici Drupal in C. Damien e dhthwy hanno creato l'estensione PHP su http://drupal.org/project/drupal_php_ext . O fai hiphop. Non conosco lo stato attuale di hiphop e Drupal 7.

Alla fine della giornata, tuttavia, è necessario esaminare attentamente i costi di progettazione, ad esempio, di far lavorare hiphop con Drupal 7 (e tutto il contributo!) E confrontarlo con l'affitto di qualche altro server. Se riesci a risparmiare, dì il 5% dei tuoi server e hai 100000 server, provaci, ma sei Facebook? Sii attento ed economico con le ottimizzazioni.


Grazie, ho aggiornato la domanda e rimosso il tuo nome da essa. :) Mi rendo conto che per molti casi, ci sono modi molto più efficienti per gestire le prestazioni, ero per lo più curioso.
Letharion

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.