Perché PHP Symfony sfSessionStorage :: initialize a volte richiede davvero molto (molto) tempo?

Question

Abbiamo diverse App per PHP, sia in symfony 1.4 che in symfony 2, e tutte, ad un certo punto, hanno richieste in cui sfSessionStorage :: initialize richiede molto tempo.

Sto parlando di diversi minuti da caricare. Prendete questa traccia newrelic ad esempio:

Qui potete vedere sfSessionStorage :: Initialize ha 185 secondi. Abbiamo eseguito il debug di questo per diversi giorni, senza successo finora. Abbiamo esaminato le impostazioni GC, l'evento ha provato a montare dove le sessioni sono archiviate nel filesystem in un RamDisk, senza alcun effetto.

Quale potrebbe essere la causa di questo? Hai mai incarnato lo stesso problema? Qualsiasi aiuto è molto apprezzato, grazie!

Answer 1

Grazie al commento di @SomeHelpingDude che punta a questo thread: https://forums.powweb.com/showthread.php?t=77977, è stata menzionata la possibilità di implementare il proprio gestore di sessione (http://www.php.net/manual/en/function.session-set-save-handler.php).

Abbiamo fatto questo, e implementato un gestore di sessione che utilizza memcached. Ora il problema è finito.

Sto assumendo che il modo nativo di gestione delle sessioni (file system) finisca per soffrire di deadlock e altri problemi di prestazioni che possono essere evitati solo non utilizzando il filesystem.

Sono ancora perplesso sul motivo per cui un ramdisk non ha risolto questo in primo luogo, quindi se qualcuno può spiegare questo cambierò la risposta accettata. Grazie!

Answer 2

Non sicuro che ciò possa essere d'aiuto, ma controllare.

Se la gestione della sessione manualmente allora si dovrebbe fare Sessions Spegnimento, in frontend/config/factories.yml

all: 
    storage: 
    class: sfSessionStorage 
    param: 
     auto_start: false 

Si dovrebbe vedere Deactivating the Unused Features per aumentare le prestazioni.

Solo un altro supposizione:

sessioni dipendono da file. Quindi controlla che il tuo sistema sia in grado di rendere aperti molti file necessari per le sessioni. O c'è qualche problema per la creazione di file.

Answer 3

strace potrebbe far luce su quello che sta succedendo.

Supponendo che non è possibile riprodurre il problema con cli, consiglio di limitare il numero di processi a 1 (MaxRequestWorkers per mod_php e max_children per php_fpm), fissare strace per il processo e controllare dove si blocca.

Per esempio nel caso in cui php_fpm:

• aperta /etc/php5/fpm/pool.d/www.conf e garantire impostazioni

  pm = static 
  pm.max_children = 1 
  

• riavvio php_fpm e nginx

• grep aux | php per scoprire l'ID del processo
• sudo strace -p seguito dal processo id
• provare a riprodurre il problema

Se si attacca per minuti con una sola chiamata di sistema, potrete vedere chiaramente il diritto bloccante nella stdout di strace. Se non esiste un singolo blocco, ma piuttosto un lungo ciclo di chiamate di sistema ripetute, sarà probabilmente necessario registrarlo su un file e analizzarlo in un secondo momento. Per esempio. sudo strace -p {pid} | tee /tmp/strace.log.

Se il problema non è riproducibile con un singolo operatore, provare ad aumentare il numero di worker e acquisire strace per tutti i processi.