it-swarm.it

Che cosa contribuisce a drupal tempo di esecuzione della pagina?

Ho un sito che sto esaminando che presenta importanti problemi di prestazioni, usando memcache sono stato in grado di ridurre il numero di query sia in numero che in termini di tempo di esecuzione totale (da 3 secondi a 230 ms) ma il tempo di esecuzione della pagina mi sta sfuggendo (lo sono guardando i valori emessi dallo sviluppo) la mia comprensione è che il tempo di esecuzione della pagina = tempo impiegato per l'esecuzione di php, quindi ho installato APC e posso vedere il codice operativo php essere memorizzato nella cache e le statistiche mostrano gli hit nel pannello di controllo APC (apc.php fornito con APC) ma il tempo di esecuzione della mia pagina non diminuisce. Quindi penso che la mia domanda sia duplice:

  • Che cosa contribuisce a (rallenta meglio) i tempi di esecuzione della pagina? Ci vuole solo tempo per eseguire php?
  • Quali approcci dovrei adottare per ridurre i tempi di esecuzione della pagina. Ho provato APC ma non molto aiuto

Il numero di moduli P.S utilizzati in questo sito è semplicemente enorme (168) ma in questo momento non sono in grado di formulare tale raccomandazione, è più simile a un incendio nella situazione del buco.

Modifica: Output di esecuzione di xhprof su istanza locale (raccomandato da mikeytown), questo sembra essere pazzo Penso che i risultati successivi siano dovuti al thrashing? diff funziona per lo stesso url ha una differenza drastica e il suo utilizzo eccessivo delle risorse. Inoltre, non so perché sta mostrando valori che non sono di oggi: | (Ho appena installato xhprof su questo laptop)

Output of running xhprof on local instance

16
Dipen

Ottieni un cachegrind del tuo sito. xdebug o xhprof può generarne uno. Questo ti dirà quali funzioni impiegano più tempo per essere eseguite. Fino a quando non lo fai, è un brutto gioco d'ipotesi.

4
mikeytown2

EDIT: ho letto male il post originale. 168 moduli sono molti e da 300 a 700ms di query SQL sono enorme. Più moduli utilizzerai, più query arriveranno non appena i moduli ne eseguiranno alcuni.

Usa la cache aggressiva finché puoi, memorizza nella cache tutto, se non è abbastanza, prova una cache proxy inversa. L'uso di una CDN per i file può migliorare notevolmente il tutto. Una cache del proxy inverso può anche aiutarti rimuovendo alcuni cookie di autenticazione quando colpisce le pagine che non ne hanno bisogno (quindi il core penserà che l'utente sia anonimo per quelli e massimizzerà la memorizzazione nella cache).


Il Drupal core dinamismo rallenta tutta l'alba non appena si hanno troppi moduli che interagiscono contemporaneamente.

Direi, ad esempio, se usi molti moduli che caricano i dati al momento hook_node_load () invece di usare i campi, farà molte domande mentre l'uso del campo avrebbe garantito l'efficienza della cache.

Anche il rendering può richiedere molto tempo, drupal_render () (l'API di rendering a volte chiamata) è un bel pezzo di API (davvero utile) ma anche un po 'lento. Il passaggio a PDO (D7) e al DBTNG completo (il che è fantastico tra l'altro) aggiunge anche una latenza non trascurabile.

Detto questo, il core di per sé è piuttosto veloce (ma fa troppe query SQL, anche con quasi nulla installato), i moduli scarsamente codificati spesso rappresentano il collo di bottiglia.

APC può dividere il tempo di esecuzione per 2 o 3, a seconda del codice che viene eseguito. se lo configuri bene (abilita tutte le ottimizzazioni APC, il manuale ufficiale APC è ben scritto e ti guiderà).

Se ci si trova in una scatola con un file system lento (file system di rete o disco rigido lento), ciò può implicare un impatto visibile sui tempi di esecuzione. Drupal è costituito da molto di piccoli file, che forza PHP a fare I/O su FS ogni volta che ne carica uno (APC aiuta anche molto per quello).

Un DBMS configurato in modo errato può anche essere un brutto collo di bottiglia, se stai usando MySQL pensa a fare una messa a punto. Se sei su un hosting condiviso, se non è Drupal specifico (o pronto) DBMS e PHP stack sarà probabilmente configurato in modo errato o non ottimizzato, che può portare a siti molto lenti.

Non dimenticare di attivare tutte le cache. Se il tuo sito non è autenticato orientato all'utente, attiva la cache di pagina aggressiva (è davvero incredibile).

Più avrai blocchi, più le pagine complete saranno lente, i blocchi di moduli di Views saranno un collo di bottiglia all'alba (a seconda dei plug-in di Views che usi, il blocco di OG può essere una vera seccatura) se non ne limiti la visibilità su una base per pagina, o con custom PHP (anche qualsiasi altro blocco, imposta sempre manualmente la visibilità del tuo blocco, aiuta notevolmente il framework evitando che tenti di renderizzare blocchi vuoti).

Evita i moduli che usano hook_init (), hook_init () viene eseguito su ogni pagina, anche se ottieni un 403 o un 404, che rallenta tutto (rallenta persino il tempo di generazione dello stile di imagecache |, e 404 errori sui file sarebbero alba lenta solo per dirti che il file non esiste).

1
Pierre