Ho creato un sito D7 con un sottotema Minelli. Lungo la strada ho sperimentato molto con temi diversi, moduli diversi. Da qualche parte lungo la strada ho sviluppato uno strano problema di prestazioni, e ora non so davvero quale tema / modulo / config lo abbia causato.

Il problema è che quando visito il sito per la prima volta, ci vogliono circa 15 secondi prima che venga mostrata la prima pagina. Posso quindi spostarmi nel sito ed è molto reattivo. Se lo lascio per circa un'ora, poi torno ad esso, la prima richiesta è di nuovo molto lenta.

Ho cancellato la cache in modo che non dovrebbe essere il problema. Inoltre, ho disabilitato temi e moduli che non sto usando. Ho spostato il sito su una nuova infrastruttura ma il problema lo ha seguito!

Dove andrò dopo?

Ci sono tre cose che vorrei controllare.

Uno, se ti trovi in ​​un sito di produzione e non stai modificando i file PHP, dovresti assicurarti che APC sia abilitato, abbia memoria sufficiente e abbia un TTL lungo (potresti passare un giorno o non scadere mai se lo desideri). Puoi anche considerare l'impostazione apc.stat=0. I documenti APC contengono tutte le informazioni necessarie per impostare il TTL. Per scegliere la quantità di memoria, dovresti incollare il file apc.php da qualche parte protetto e monitorare l'utilizzo della memoria e le statistiche di churn. Regola la memoria APC in modo che il tuo tasso di mancato raggiungimento sia molto basso. La lentezza iniziale potrebbe essere dovuta al fatto che APC è pieno e svuotato (IIRC, APC scarica l'intera cache quando è piena invece di impiegare LRU o strategie di cache più avanzate).

In secondo luogo, assicurati di avere MySQL ottimizzato in modo appropriato. È possibile utilizzare mysqltuner per regolare le dimensioni del buffer. La lentezza iniziale potrebbe essere dovuta al caricamento di tabelle dal disco e / o mancate query cache. Sebbene non sia perfetto, mysqltuner ti porta nella giusta direzione.

Terzo, assicurati di avere una vera strategia cron Drupal . Personalmente, disabiliterei automagic cron su "admin / config / system / cron" e configurerei un crontab per l'esecuzione ogni notte. Puoi anche provare Elysia Cron se hai davvero bisogno di un controllo più preciso sulle cose. In questo modo è possibile eseguire le attività necessarie tutte le volte che è necessario, ma far eseguire quelle normali durante la notte. La tua lentezza iniziale potrebbe essere dovuta a corse cron che si verificano ogni ora. Puoi confermarlo osservando quando cron viene eseguito su "admin / reports / dblog" e cercando di far coincidere la tua lentezza.

Ivanhoe123 ha probabilmente ragione: Drupal 7 viene fornito con 'poor mans cron' abilitato di default. In breve, significa che (una volta ogni tanto) cron viene eseguito prima che Drupal esegua il rendering della pagina, ritardando tutto.

Cerca sempre di utilizzare un lavoro cron reale nei siti di produzione. Per ulteriori dettagli tecnici, consultare http://drupal.org/cron o parlare con la società di hosting.

Per disabilitarlo, vai su admin / config / system / cron e seleziona 'Mai'.

Il modulo Devel offre la registrazione del database per verificare se sono presenti query di lunga durata.

Se questo non aiuta a prendere XHProf o XDebug e trovare il codice colpevole. XHProf (un profiler) ti disegna una bella mappa di tutte le funzioni che vengono eseguite sul server e ti dice quali stanno consumando più tempo di esecuzione. D'altra parte, quando XDebug (un debugger) è configurato con un IDE come Eclipse ( vedi video ), ti permette di approfondire tutte le funzioni eseguite LIVE. Il profiler ti darà un'idea di ciò che viene eseguito; mentre il debugger ti mostrerà perché viene eseguito.

Proprio dal sapore della domanda, penso immediatamente a tre (3) cose

• MySQL Storage Engine / CPU
• Memorizzazione nella cache del database
• Blocco della tabella

MySQL Storage Engine

Se non stai utilizzando alcuna ricerca / indicizzazione FULLTEXT, ti consiglio vivamente di convertire tutti i tuoi dati MyISAM in InnoDB. MyISAM non è progettato per sfruttare più CPU e più core. InnoDB è stato notevolmente migliorato per l'utilizzo di più CPU e per l'hyperthreading in lettura / scrittura.

Ecco alcuni post che ho fatto a riguardo in StackExchange DBA e in questo sito per quanto riguarda la messa a punto di MySQL per InnoDB Performance

• Sep 20, 2011: Multi core e prestazioni MySQL
• Sep 12, 2011: È possibile fare in modo che MySQL utilizzi più di un core
• Jun 07, 2011: Come posso convertire un database da MyISAM a InnoDB?
• May 26, 2011: Informazioni sulle prestazioni di database a thread singolo o multithread
• Apr 15, 2011: https://drupal.stackexchange.com/questions/1715/what-would-be-the-optimal-mysql-configuration-for-a-drupal-7-site/2367#2367

Memorizzazione nella cache del database

Un altro argomento forte per convertire tutti i dati MyISAM in InnoDB è come MySQL memorizza nella cache dati / indici. MyISAM Storage Engine memorizza solo nella cache gli indici. InnoDB memorizza nella cache dati e indici . Alla luce di ciò, è possibile allocare memoria sufficiente per il pool di buffer InnoDB per ospitare uno dei seguenti (qualunque sia il più piccolo)

• Tutti i dati e gli indici InnoDB (ideale se si dispone di RAM sufficiente anche per il sistema operativo; elimina i ritardi successivi)
• 75% di RAM installata (nel caso in cui si disponga di più dati / indici InnoDB rispetto alla RAM; minimizza i ritardi)

Se si utilizza MySQL 5.1, è possibile impostare innodb_max_dirty_pages_pct = 0. Questo aumenterà leggermente l'I / O del disco, ma il pool di buffer InnoDB verrà cancellato abbastanza da consentire ai vecchi dati e alle pagine di indice di ruotare senza picchi di I / O del disco. MySQL 5.5 e il plug-in InnoDB di MySQL 5.1 non necessitano di questa regolazione poiché ha un meccanismo di svuotamento del pool di buffer predefinito migliore.

Se l'utilizzo di InnoDB è fuori discussione, potrebbe essere necessario utilizzare memcached o vernice. Ciò consente allo sviluppatore di stabilire per quanto tempo i dati memorizzati nella cache rimarranno nella RAM del server. Naturalmente, ciò richiederà un miglioramento dello sviluppo per rendere la vostra applicazione memcached / vernice-consapevole.

Blocco della tabella

• InnoDB esegue il blocco a livello di riga, che consente transazioni e letture senza blocco .
• MyISAM esegue il blocco completo della tabella solo per INSERT, UPDATE e DELETE .

Epilogo

Non è possibile evitare un ritardo iniziale dopo un riavvio di MySQL. Tuttavia, una volta migliorato MySQL utilizzando i suggerimenti / informazioni di cui sopra, non si dovrebbero più riscontrare ritardi successivi.

Vorrei utilizzare strumenti come YSlow o Firebug ecc. Per determinare esattamente cosa sta succedendo quando carichi detta pagina e quando carichi detta pagina immediatamente dopo. Verifica se si tratta di un problema di memorizzazione nella cache e, inoltre, controlla come funziona quando accedi alla pagina come utente anonimo e quindi come utente autenticato. Confronta questo con le tue impostazioni di performance in Drupal.

Se non si tratta di un problema di memorizzazione nella cache, utilizzare il registro delle query di Devel così come i registri di MySQL per vedere cosa sta succedendo nel database. Inoltre, se si dispone di un codice operativo o di cache simili per il miglioramento delle prestazioni sul server, provare a rimuovere alcuni numeri e riaccenderli.

Sembra che il cron sia in esecuzione.

Controlla le tue impostazioni qui: admin / config / system / cron

Per questo motivo ho quasi lasciato cadere Drupal per il mio ultimo progetto.

Devo però avere più di una causa. Devo ancora trovare una soluzione "ripara tutto" che funzioni ogni volta che si presenta questo problema.

Syslog e Ubuntu / Debain

La prima volta che ho incontrato il tempo di caricamento intermittente di 15 secondi è stato mentre eseguivo drupal su sistemi basati su Debian / Ubuntu (dedicati, non condivisi). Disabilitare il modulo Syslog è stata la soluzione per me.

Come ha detto @BetaRide, l'uso di xDebug o di altri profili di PHP è estremamente illuminante.

Ancora un problema: una soluzione alternativa

Per quanto riguarda le mie altre installazioni, sono ancora in perdita.

Questo problema è più evidente sul mio server di sviluppo e sulle mie installazioni Drupal a basso traffico.

Come soluzione alternativa ho impostato un processo cron per caricare la home page dei siti ogni 60 secondi e lo script cron di Drupal ogni 300 secondi. Questo ovviamente non è ottimale, ma preferirei sperare o arricciare il tempo di caricamento di 15 secondi anziché un visitatore umano.

Molte persone suggeriscono che questo problema potrebbe essere correlato al blocco di processi in background sincroni , in particolare relativi a lavori cron pesanti .

Se fosse vero, esiste una grande coppia di moduli in fase di sviluppo attivo di gielfeldt * che potrebbero eliminare questo problema o, almeno, potrebbero offrire alcuni indizi e aiutare i costruttori di siti a diagnosticare e trattare specifici colpevoli nei loro casi. Entrambi sostituiscono i processi sincroni di blocco con HTTP o comandi asincroni non bloccanti ed entrambi offrono report pertinenti in grado di identificare i processi problematici:

• Il processo in background e i suoi moduli raggruppati consentono l'elaborazione in coda in modo asincrono dei processi in background di Drupal, in modo che non si blocchino. Questo potrebbe fermare il problema. Inoltre, con il modulo Apache Server in background del processo in bundle nell'ultimo sviluppo, esiste un rapporto dell'interfaccia utente di base ma migliorante con funzionalità per supervisionare, sbloccare e ispezionare i tempi di avvio e l'avanzamento di questi processi. Questo potrebbe identificare il processo problematico.
• Ultimate Cron si basa sul processo in background per consentire alle attività attivate da cron di avere i propri scehdules asincroni separati, ognuno dei quali può essere monitorato e arrestato in un'interfaccia utente. Oltre ad essere ottimo per separare le attività pesanti che indeboliscono le prestazioni dalla normale pulizia a basso costo, ti dà anche un rapporto con informazioni utili come la durata di esecuzione di ogni singola attività innescata da cron, quando vengono eseguite l'ultima volta, lo stato corrente, ecc. Ciò potrebbe anche rimuovere il blocco e / o identificare i processi problematici.

Entrambi sono comunque moduli molto utili; per questo problema, possono essere usati per testare la teoria (molto plausibile del suono) secondo cui i blocchi sono causati da processi di blocco sincrono o cron run. Potenzialmente, potrebbero risolvere il problema eseguendoli in modo asincrono anziché sincrono, e potrebbero anche offrire indizi su quali processi specifici stessero causando il blocco. (attenzione che la loro documentazione è in gran parte un lavoro in corso ...

Se, tuttavia, non possono essere configurati per aiutare affatto, ciò suggerisce che c'è di più nel problema oltre ai semplici processi in background sincroni. FWIW, non ho mai avuto questo particolare problema su un sito da quando questi moduli hanno funzionato correttamente (ancora - touch wood) - ma l'ho già visto sui miei siti, così come su siti live di Drupal in natura.

Prestare inoltre attenzione ad altri moduli plug-in correlati attualmente in fase di sviluppo, ad esempio in casi complessi ad alta intensità, Ultimate Cron Queue Scaler , che consente la limitazione basata su soglia, potrebbe aiutare a ridurre i problemi di prestazioni relativi a cron.

* nessuna affiliazione, sono solo un utente molto colpito del loro lavoro

Dal momento che questo mi sta colpendo ancora una volta ho iniziato a indagare sul problema. Posso sicuramente confermarlo

1. una chiamata drupal_cron_run()innescata dal cron del core di Poorman aggiunge ~ 5 secondi al tempo di richiesta sulla mia macchina di sviluppo. Questo può essere testato decommentando i test attorno alla chiamata drupal_cron_run()in modules/system/system.moduleinsystem_run_automated_cron()
2. svuotare tutte le cache aggiunge ~ 2 secondi al tempo di richiesta sulla mia macchina di sviluppo. Questo può essere testato eseguendo un drush cc alle ricaricando nuovamente la pagina.

Ciò significa che l'impostazione di cron su never e l'aggiunta di una chiamata a cron tramite crontab rendono la situazione molto migliore. Colpire alcune pagine spesso utilizzate subito dopo per riempire la cache migliorerebbe nuovamente l'esperienza dell'utente.

Non sono sicuro però della memorizzazione nella cache. Non ho toccato le impostazioni della cache predefinite per questo sito. Penso che drupal stia ricostruendo tutte le cache di tanto in tanto forse innescate da cron, ma non sono sicuro di come sia fatto. Ma un ritardo di 7 secondi è praticamente quello che vedo quando tocco la pagina dopo alcune ore.

Problemi come questo possono farti impazzire e quando ero in situazioni simili aiuta a capire cosa sta causando il problema andando un passo alla volta e quindi testarlo come utente anonimo e registrato. (metodo dello strato di cipolla)

Dici che inizi a notare il problema dopo aver giocato con un paio di temi e personalizzato il tuo codice. Non so quanto sia complesso il tuo sito né la logica dietro di esso, ma i seguenti passaggi ti aiuteranno a trovare il problema:

1. Nel tuo server crea una cartella o un altro account (potrebbe essere meglio) in cui eseguirai un'installazione pulita di Drupal con la stessa versione che stai utilizzando sul tuo sito. Quindi, senza aggiungere alcun modulo o test a tema, il tempo impiegato dal sito per rispondere alla prima richiesta e alla richiesta successiva. Se tutto funziona bene, puoi ignorare i problemi di configurazione del server, se si comporta come il tuo attuale, hai un errore di configurazione con il tuo server web o database.

2. Se i risultati del passaggio 1 sono positivi e il server risponde rapidamente e le seguenti richieste sono altrettanto veloci, installare solo il tema del sito corrente nel sito di installazione pulito e testarlo di nuovo. Se tutto continua a rispondere rapidamente, il tuo tema non è il problema e dovresti continuare con il passaggio 3, altrimenti devi iniziare il debug del tema * 1.

3. Se dopo i test del passaggio 2 il sito continua ancora rapidamente a portare i moduli nel tuo sito corrente e assicurati di testare il tempo di risposta dopo aver aggiunto e abilitato ciascun modulo * 2.

4. Se dopo aver aggiunto il tema e i moduli il sito continua a rispondere rapidamente, iniziare ad aggiungere la configurazione, creare tipi di contenuto, importare visualizzazioni, menu di impostazione, ecc. Non dimenticare di testare la risposta del sito dopo aver aggiunto ciascuno.

5. L'installazione e la configurazione sono pronte e il sito è ancora veloce, quindi ora riporta i dati. Importare nodi, termini di tassonomia, commenti, ecc. So che devo suonare come un record rotto, ma testare sempre dopo aver completato ogni passaggio.

* 1 Temi di test: questo processo può essere complicato in un tema super elaborato, ecco alcuni suggerimenti:

1. Se si collega a una libreria js o css esterna, provare a utilizzare una copia locale della stessa.

2. Nel tuo file template.php controlla la funzione che potrebbe avere loop più lunghi o infiniti, nonché la funzione di preelaborazione e / o le funzioni del tema hook.

3. Controlla altri file modello (page.tpl.php, ecc.) E cerca l'elaborazione PHP grezza di matrici e oggetti.

4. Se usi "Viste" e visualizza i file modello, controlla anche allora.

5. Controlla sempre i percorsi, ottimizza le immagini, i file js e css. A volte i file js possono avere una certa altezza quando si usano più frammenti di codice in un singolo file.

* 2 Moduli di test : i moduli di test sono leggermente diversi perché è consentito l'uso di manipolazioni pesanti con PHP. Ecco alcuni suggerimenti:

1. I moduli supportati dalla community (CCK, Views, ecc.) Hanno problemi in coda su drupal.org controllali per vedere se c'è qualche problema esistente sul tuo problema e se ci sono possibilità che ci sia una patch per risolverlo.

2. Proprio modulo personalizzato codificato, bene se hai codificato devi ripararlo, giusto ?. Controlla la tua codifica e verifica l'utilizzo delle funzioni rispetto a api.drupal.org, potresti utilizzare una funzione di overkilling anziché un hook.

3. Modulo di codice personalizzato condiviso su Internet, fai come nel passaggio 2, ma questa volta puoi anche contattare l'autore del modulo originale e fargli conoscere il problema.

4. Se il tuo sito è un aggiornamento (D5 -> D6 -> D7) controlla gli script di migrazione o aggiornamento (di solito nel file module.install) potresti aver bisogno di un "indice" extra sulla nuova configurazione della tabella per rendere più veloce la query SQL X .

5. Se ritieni di avere una visione a tunnel del problema, esci un po 'e fai qualche altra attività completamente non correlata, quindi torna più tardi per rivisitare il problema.

6. Se esegui il ping del problema su una sezione di codice, ma non riesci a capire come risolverlo, prova a spiegare che cosa deve fare quella sezione a una persona che non ha idea di come programmare o come funziona ed essere Drupal pronto per essere sorpresa.

Nota: non allarmarti se dopo aver ricostruito il tuo sito tutto inizia a funzionare come un incantesimo che è una delle migliori caratteristiche dei computer.

Controlla di non aver eliminato alcun modulo senza disinstallarli. Ciò causa un ritardo perché Drupal tenta di trovare i file ma non sono più presenti.

Elimina i riferimenti nella tabella delle variabili se i moduli non esistono più.

Un APM Web come newrelic è lo strumento migliore per rintracciare i problemi di prestazioni. Ho avuto siti che chiamavano una o due righe di codice che facevano cose traballanti, caricavano array inutili in tempi strani e facevano altre cose che erano piuttosto invisibili fino a quando non li abbiamo rintracciati con un APM.

Qualcuno ha detto che GoDaddy sarà lento. Molte aziende di hosting basate su cloud avranno anche questo ritardo iniziale perché servizi come AWS ce l'hanno. È più economico avere i server deprioritizzati automaticamente e quei server richiederanno un secondo o due per "svegliarsi".

Ad esempio, Pagodabox ha 3-4 secondi per il primo byte, fino a quando il server è felicemente sveglio. Pagodabox ha infatti monetizzato mantenendo sveglio il server e quindi puoi pagare un extra per "caffienate" il tuo sito.

Inoltre, un CDN può aiutarti. Il tuo server web / db non verrà caricato con la pubblicazione di pagine o immagini memorizzate nella cache. Un buon tutorial qui: http://wimleers.com/article/easy-drupal-cdn-integration-for-fun-and-profit

E ... WebPageTest mi rende felice. http://www.webpagetest.org/ Confronta i tempi di caricamento in tutto il pianeta e con diversi browser web gratuitamente. Usa questo per ottenere risultati reali per qualsiasi cambiamento tu stia facendo.

il problema potrebbe essere ovunque.

1. Assicurati di non aver attivato la modalità debug su nessun tema o modulo. Ad esempio, in molti temi esiste un'opzione per rigenerare il registro dei temi.
2. Se si esegue l'hosting condiviso come Godaddy, 15 secondi per la prima volta la richiesta è normale.
3. Converti il ​​tuo sito o la tua pagina iniziale in codebase usando il modulo Drush CTools Export . Ciò eliminerà qualsiasi chiamata al database e il tuo sito verrà eseguito interamente da PHP.
4. Se i problemi persistono, utilizzare le impostazioni di Develop attivando query loge page timeropzioni su admin/config/development/devel. Scopri quale dei due richiede più tempo per generare l'intera pagina.
5. Riavvia il server se non funziona nulla.
6. Nel peggiore dei casi, installa XHProf per vedere dove stanno andando le cose.

Quindi è così che ho risolto il problema per la mia installazione. Non è una soluzione reale in quanto non potrei inchiodare la fonte esatta del problema (se ce n'è uno), ma è una buona soluzione

1) CSS aggregato (impostazioni della cache). Ciò ha ridotto la latenza della metà

2) Impostare cron su never (ed eseguirlo esternamente) - Nota: ho avuto errori "tentando di avviare cron mentre è già in esecuzione". Penso che stesse cercando di avviare cron ad ogni avvio, ma poiché non è riuscito, la pagina cron non menzionava l'ultimo tentativo, ma piuttosto l'ultimo successo.

3) Configurare un processo cron che chiama la home page con Lynx ogni 30 minuti

Tutto questo su un server di hosting condiviso. Non è ottimale ma funziona

Suggerirei di utilizzare una cache front-end lungo le linee del modulo Boost (supponendo che tu sia in hosting condiviso) o Varnish. Funzionerà meglio se gli accessi al tuo sito sono principalmente anonimi e il contenuto della pagina è, per la maggior parte, non dinamico (cioè le pagine non cambiano molto).

Queste soluzioni salvano le pagine renderizzate al primo accesso e quindi servono l'html pre-renderizzato anziché passare attraverso l'intero bootstrap Drupal, la creazione di pagine e i processi a tema, risparmiando MOLTO tempo, specialmente su siti occupati ma anche su siti come te descrivere quale "andare a dormire" e impiegare troppo tempo a svegliarsi.

L'unico vero svantaggio è che (almeno per Boost) dovrai svuotare la cache quando il contenuto del sito cambia. Se vuoi assicurarti che il sito sia completamente memorizzato nella cache con il contenuto corrente, puoi eseguire drush cc all e quindi curl o wget periodicamente contro l'intero sito tramite cron.