Długi czas odpowiedzi dla Mage_Core_Model_Session_Abstract_Varien

Zauważyłem więc w New Relic na wielu naszych stronach, wiele ładowań długich stron dzieje się z powodu Mage_Core_Model_Session_Abstract_Varien :: start. Przeprowadziłem badania i naprawdę nie widziałem, żeby ktokolwiek mówił o tym.

Używamy Nginx, PHP FPM, Redis do buforowania i Memcache do sesji. Niektóre z moich pomysłów są takie, że być może jest to coś, co trwa wiecznie i wydaje się, że problem stanowi ładowanie sesji. Lub w jakiś sposób istnieje niestandardowy kod dodający do sesji dużo danych, co powoduje ogromne sesje.

Nie mam wystarczającej wiedzy na temat sesji i sposobu zarządzania nimi, ale znalazłem kilka artykułów mówiących o blokowaniu sesji. Jednak nie sądzę, że ludzie będą otwierać tak wiele stron jednocześnie.

Niektóre z tych obciążeń trwają około 20-30 sekund. Jestem ciekawy, czy ktokolwiek to zauważył lub miał więcej wiedzy na temat analizowania tego rodzaju długich próśb z powodu sesji.

performance session

— dan.codes
źródło

Zauważyłem to samo zachowanie w przypadku Redis używanego do przechowywania sesji. Żadnych wskazówek, dlaczego tak się dzieje.

Czy udało ci się już znaleźć przyczynę tego? Mam bardzo podobną konfigurację (Redis dla pamięci podręcznej, memcached dla sesji) i niedawno zaczęliśmy używać New Relic do śledzenia wydajności. Łapiemy ponad 20 sekund drugich śladów, które wydają się być spowodowane przez coś w MCMSAV :: start jak widzieliście. Niestety nie widzę go głębiej, podpowiedź mówi: „Głębsza widoczność nie jest dostępna, ponieważ te klasy i metody nie są instrumentowane przy bieżącej konfiguracji agenta PHP”. Muszę jeszcze zbadać. Jakieś pomysły?

— BrianVPS

@BrianVPS Nigdy niczego nie znalazłem. Pozostaje mi to tajemnicą i nigdy nie miałem więcej czasu na jej wyśledzenie. Nadal widzę to w każdym projekcie. Czy kiedykolwiek coś znalazłeś?

— dan.codes 28.04.16

Nie wiem, czy znaleźliśmy jakieś przyczyny, ale ostatnio tego nie widziałem. Wprowadziliśmy znaczące zmiany na stronie i usunęliśmy dużo tłuszczu. Wyłączyłem niektóre nieużywane moduły podstawowe, usunąłem mnóstwo nieużywanych atrybutów, kategorii i produktów. Od tego czasu rzeczy ulegają poprawie na wszystkich frontach. Nie wiem, czy którykolwiek z nich był powiązany, ale ogólnie pozbywanie się niepotrzebnych rzeczy wydaje się znacznie pomóc Magento. To potężny, ale rozdęty system z dużą ilością kodu, którego wiele stron nie potrzebuje. Pozbycie się nadmiaru jest bardzo pomocne.

— BrianVPS

@BrianVPS Mam dokładnie ten sam problem, który miałeś (ponad 20 sekund śladów, które wydają się być spowodowane przez coś w MCMSAV :: start). Znalazłeś jakieś rozwiązanie?

— Denis Spalenza

Jest to najprawdopodobniej związane ze zjawiskiem dotyczącym sesji systemu plików. Pomimo tego, co raportujesz za pomocą Mecached do sesji, widziałem to tylko wtedy, gdy w rzeczywistości korzystałem z systemu plików.

Zostało to tutaj omówione wcześniej:

/magento//a/3721/336

W rzeczywistości zrzut ekranu pamięci podręcznej ujawnia dokładny moment, w którym rozpoczęcie sesji zajmuje nadmiernie dużo czasu, Mage_Core_Model_Session_Abstract_Varien::startjak prawidłowo wskazałeś:

wprowadź opis zdjęcia tutaj

W przywołanym wątku pojawiła się sugestia, że efekt ten można zmniejszyć za pomocą przechowywania sesji w pamięci - ale nie istnieją żadne konkretne dane, o których wiem, że mogłyby poprzeć teorię. Jeśli faktycznie używasz memcached, to oczywiste jest, że blokada sesji na poziomie PHP uniemożliwiłaby przyszłe żądania do przechowywania sesji do momentu zwolnienia blokady.

Zasadniczo jest to widoczne tylko w przypadku żądań wymagających dostępu do informacji o sesji, więc zaprojektowanie kompozycji interfejsu użytkownika będzie korzystne, aby ograniczyć ilość potrzebnego dostępu, aby uniknąć potencjalnych blokad, gdy użytkownik ma inną kartę lub inne długotrwałe żądanie w trakcie podejmowania decyzji odejść.

HTH, zdrowie.

— philwinkle
źródło

Długi czas odpowiedzi dla Mage_Core_Model_Session_Abstract_Varien :: start