Pytanie w sprawie apache, fastcgi, php, session, debian – session_start wydaje się być bardzo powolny (ale tylko czasami)

25

Z jakiegoś dziwnego powodu, dzisiaj nasz serwer zdecydował się na bardzo powolny start sesji. Dla każdego początku sesji serwer wygaśnie po 30 sekundach, a uruchomienie sesji zajmie około 20 sekund. Jest to bardzo dziwne, ponieważ nie robi tego od bardzo dawna (ostatni raz nasz serwer to zrobił około 7 miesięcy temu). Próbowałem zmienić sesję tak, aby była uruchamiana przez bazę danych, a to działa bez zarzutu, jednak ponieważ nasza obecna strona jest zbudowana, przejście na każdą stronę i zmiana ładowania sesji w celu włączenia nowej sesji zajęłoby kilka dni treser. Dlatego pozostaje moje pytanie:

Dlaczego jest tak wolno i dlaczego tylko czasami?

Pracujemy na dedykowanym serwerze hetzner z 24 GB pamięci RAM i wystarczająco szybkim CPU, aby uruchomić prosty serwer WWW (jak sądzę Xeon, ale nie jestem pewien). Uruchamiamy debian na serwerze z instalacją apache + fastcgi + php5.

Serwer nie zgłasza dużego obciążenia ani przez status serwera, ani przez serwertop dowództwo.Vnstat nie zgłasza żadnego problemu z naszym łączem sieciowym (ponownie, co nie spowodowałoby powolnej obsługi sesji lokalnej).IOtop nie zgłasza problemu z procesami przejmującymi cały dysk twardy. Zapis do folderu tmp, w którym znajdują się pliki sesji, działa szybko, jeśli jest wykonywany przez vim.

Ponownie, aby to wyjaśnić, moim głównym zmartwieniem nie jest to, czy powinniśmy przełączyć się na DB lub buforowaną w pamięci wersję sesji, po prostu zapytać, dlaczego tak się dzieje, ponieważ wszystko, na co patrzę, wydaje się działa dobrze, z wyjątkiem samego PHP.

EDYTOWAĆ: Maksymalny plik w naszym katalogu PHP tmp to 2,9 MB, więc uważam, że nic nie powinno mieć wpływu.

AKTUALIZACJA: Nigdy nie odkryłem, co było nie tak i / lub jak to naprawić, ale problem zniknął po przełączeniu na sesje memcached / db.

@happybuddha Jak już zaktualizowałem w OP, skończyło się na przełączaniu się na sesje buforowane pamięci, po tym jak to się stało ponownie. Nie dokonano wcześniej żadnych zmian, a problem losowo (przynajmniej wydaje się przypadkowy) znika ponownie. (Uwaga: to pytanie ma 11 miesięcy). h2ooooooo
„zajęłoby wiele dni, aby przejść na każdą stronę i zmienić ładowanie sesji, aby włączyć nowy program obsługi sesji”. Jeśli tak, to poważnie powinieneś rozważyć naprawienie tego faktu w pierwszej kolejności PeeHaa
Związane zstackoverflow.com/q/13772074/168034 phunehehe
RepWhoringPeeHaa @ Jak już wspomniałem, zdecydowanie bym to zrobił. Zostałem przeniesiony do systemu z moją pracą, więc niestety nie stworzyłem zarządzania sesjami, które miała aplikacja. To nie było coś, co musieliśmy naprawić, ponieważ, jak wspomniano, nie było problemu przez ponad 7 miesięcy. h2ooooooo

Twoja odpowiedź

6   odpowiedzi
0

Każda sesja jest przechowywana przez apache jako plik tekstowy.

Kiedy uruchamianie sesji jest używane do wznowienia istniejącej sesji (na przykład przez identyfikator pliku cookie), może duży plik sesji (sesja z dużą ilością treści wewnątrz) może być powolny do uruchomienia?

Jeśli tak jest, prawdopodobnie aplikacja wprowadza wiele danych do sesji.

Największy plik w naszym folderze tmp to 2,9 MB, więc nic takiegopowinien wywierać wpływ. h2ooooooo
2

Wpadłem też na ten problem. Odpowiedzi tutaj:

Problem z funkcją session_start () (działa powoli)

Sesje są blokowane przez PHP podczas wykonywania jednego skryptu, więc jeśli skrypty są ułożone w tej samej sesji, mogą powodować te zaskakująco długie opóźnienia.

Chciałbym, żeby to po prostu to naprawiło, ale to dziwne, jak to się stało z KAŻDYM użytkownikiem na stronie (w tym dostęp z naszego biura na różnych komputerach), jeśli jest to po prostu plik sesji zablokowanej. Może to dlatego, że użyliśmy plików tekstowych i dlatego używałpodobnie plik, który był zablokowany? h2ooooooo
5

Miałem ten sam problem: nagle serwer potrzebował 30 sekund na wykonanie żądania. Zauważyłem, że to z powodusession_start (). Pierwsza prośba była szybka, ale każda kolejna prośba miała trochę30 sek do wykonania. Odkryłem, że plik sesji w c: wamp mp został zablokowany przez pierwsze żądanie przez około 30 sekund. W tym czasie drugie żądanie czekało na odblokowanie pliku. Dowiedziałem się, że ma to coś wspólnegorewrite_mod i.htaccess. Wyłączyłem rewrite_mod i skomentowałem wszystkie wiersze w .htaccess i działa to jak urok. Nie wiem, dlaczego tak się stało, ponieważ nie pamiętam, aby zmienić ustawienia lub conf na wamp.

Całkowicie zgodziłem się z tym rozwiązaniem ... ale dlaczego nie wiem. Shakeel Ahmed
0

Sprawdź, czy masz poprawne ustawienia pamięci, np. w/etc/php.d/memcached.ini

15

Czy próbowałeśsession_write_close(); ? Spowoduje to wyłączenie możliwości zapisu w zmiennych sesji, ale nadal można odczytywać z nich dane. A później, gdy musisz napisać zmienną sesji, otwórz ją ponownie.

Cierpiałem również z powodu tego problemu, ale to działało jak urok. Tym się właśnie zajmuję:

<code>session_start(); //starts the session
$_SESSION['user']="Me";
session_write_close();   // close write capability
echo $_SESSION['user']; // you can still access it
</code>
Dziękuję Ci. Myślę, że to działa teraz. Znacznie szybsze i jeszcze nie całkowite spowolnienie :) Marian Klühspies
0

Wiem, że to stare pytanie, ale właśnie naprawiłem ten problem na moim serwerze. Wszystko, co zrobiłem, to włączenie pamięci podręcznej obejścia dla domen w menedżerze pamięci podręcznej w cpanel.

Moje sesje trwały całe wieki, aby zacząć i zamknąć teraz, są natychmiastowe.

Powiązane pytania