EDIT: ho letto male il post originale. 168 moduli sono molti e da 300 a 700ms di query SQL sono enormi . Più moduli utilizzerai, più query arriveranno non appena i moduli ne eseguiranno alcuni.
Usa la cache aggressiva mentre 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 proxy inversa 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 dinamismo del core di Drupal rallenta l'intera alba non appena hai troppi moduli che interagiscono contemporaneamente.
Direi, ad esempio, se usi molti moduli che caricano i dati al momento di 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 a proposito) aggiunge anche una latenza non trascurabile.
Detto questo, il core di per sé è abbastanza 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 è composto da molti piccoli file, che costringono PHP a eseguire operazioni di 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 è lo stack DBMS e PHP specifico di Drupal (o pronto), probabilmente sarà configurato in modo errato o non ottimizzato, il 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 aggressiva della pagina (è 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 base per pagina o con codice PHP personalizzato (anche qualsiasi altro blocco, imposta sempre manualmente la visibilità del blocco, aiuta notevolmente il framework evitando che tenti di rendere 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).
