Dlaczego PHP Symfony sfSessionStorage :: initialize czasami zajmuje naprawdę (naprawdę) długi czas?

Question

Mamy różne aplikacje PHP, zarówno w Symfony 1.4, jak i Symfony 2, i wszystkie z nich, w pewnym momencie, mają żądania gdzie sfSessionStorage :: initialize trwa bardzo długo.

Mówię o ładowaniu kilku różnych minut. Weź ten newrelic ślad na przykład:

Tutaj można zobaczyć sfSessionStorage :: initialize wziął 185 sekund. Debagowaliśmy już od kilku dni, ale bez powodzenia. Zapoznaliśmy się z ustawieniami GC, próbowaliśmy montować zdarzenia, gdzie sesje są przechowywane w systemie plików na RamDisk, bez efektu.

Co może być tego przyczyną? Czy kiedykolwiek zamknąłeś ten sam problem? Każda pomoc jest bardzo ceniona, dzięki!

Answer 1

Dzięki komentarzowi @SomeHelpingDude wskazującego na ten wątek: https://forums.powweb.com/showthread.php?t=77977, wspomniano o możliwości wdrożenia własnego programu obsługi sesji (http://www.php.net/manual/en/function.session-set-save-handler.php).

Zrobiliśmy to i zaimplementowaliśmy procedurę obsługi sesji, która używa memcached. Teraz problem już minął.

Przyjmuję, że rodzimy sposób obsługi sesji (systemu plików) kończy się cierpieniem na zakleszczenia i inne problemy z wydajnością, których można uniknąć tylko przez niewykorzystywanie w ogóle systemu plików.

Nadal jestem zdziwiony, dlaczego ramdisk tego nie naprawił, więc jeśli ktoś może to wyjaśnić, zmienię zaakceptowaną odpowiedź. Dzięki!

Answer 2

Nie jestem pewien, czy to pomoże, ale sprawdź.

Jeśli obsługa sesji ręcznie wówczas należy dokonać Sesje Wyłączanie w frontend/config/factories.yml

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

Powinieneś zobaczyć Deactivating the Unused Features dla zwiększenia wydajności.

Kolejna przypuszczenie:

Sesje są zależne od plików. Sprawdź, czy twój system jest w stanie sprawić, że wiele plików będzie otwartych dla sesji. Czy jest jakiś problem z tworzeniem plików?

Answer 3

strace może rzucić trochę światła na to, co się dzieje.

Zakładając, że nie można odtworzyć problemu za pomocą cli, zaleciłbym ograniczyć liczbę procesów do 1 (MaxRequestWorkers dla mod_php i max_children dla php_fpm), dołączyć strace do procesu i sprawdzić, gdzie się zawiesza.

Na przykład w przypadku php_fpm:

• otwarty /etc/php5/fpm/pool.d/www.conf i zapewnić ustawienia

  pm = static 
  pm.max_children = 1 
  

• restart php_fpm i nginx

• grep aux | php, aby dowiedzieć się identyfikator procesu
• sudo strace -p następnie według ID procesu
• spróbować odtworzyć problem

Jeśli przykleja przez kilka minut za pomocą jednego wywołania systemowego, można wyraźnie zobaczyć prawo bloker w standardowe wyjście strace. Jeśli nie ma pojedynczego blokera, ale raczej długa pętla powtarzających się wywołań systemowych, prawdopodobnie będziesz musiał zalogować go do pliku i przeanalizować go później. Na przykład. sudo strace -p {pid} | tee /tmp/strace.log.

Jeśli problem nie jest powtarzalny w przypadku pojedynczego pracownika, spróbuj zwiększyć liczbę pracowników i przechwyć strace dla wszystkich procesów.