2014-05-06 17 views
8

O ile mi wiadomo, dla każdego klienta podłączonego do serwera PHP generuje dla niego nowy wątek. Ale zastanawiam się, czy to prawda, czy nie, i jeśli to prawda, jak długo ta żywa nitka pozostanie żywa? Czy ten wątek poprawnie utrzymuje wszystkie zmienne statyczne? (jak połączenie DB)Jak rdzeń PHP obsługuje połączenia z klientami?

Kiedy ten wątek zostanie zniszczony, czy wywoła wszystkie destruktory?

+3

Zobacz także [to pytanie] (http://stackoverflow.com/questions/14183397/php-request-lifecycle) (nie jest to dokładnie duplikat do zamknięcia) –

+1

Pytasz o 'mod_php' lub' php' ? – kojiro

Odpowiedz

6

Wszystko zależy od konfiguracji PHP z serwerem. Jestem bardziej zaznajomieni z Apache/PHP kombi (zamiast powiedzieć Nginx i FastCGI z konfiguracji PHP), więc skupienie się na tym obszarze:

  1. PHP jest zwykle zintegrowany z Apache jako DSO (Dynamic-shared-Object) moduł.

  2. Teraz Apache zazwyczaj pod Linuksem/Unixem jest zwykle konfigurowany jako model "pre-forked" - tzn. Kiedy się uruchamia, grupa procesów podrzędnych jest rozwidlana (dokładna liczba może być konfigurowana za pomocą dyrektyw Apache), oraz są w "puli procesów" gotowych do obsługi żądań.

  3. Po otrzymaniu żądania program planujący jądra wybiera proces Apache z puli (jeśli jest dostępny), a żądanie jest obsługiwane przez dziecko.

  4. Na podstawie konfiguracji Apache, jeśli wykryje, że skrypt PHP musi zostać wykonany, przekazuje go do DSO PHP jako setup (1).

  5. W związku z tym nie stosuje się rozwidlania ani gwintowania na żądanie, co jest skuteczne. Cały kontekst żądania jest przekazywany do warstwy PHP, która rozpoczyna kompilowanie i wykonywanie skryptu PHP.

    Uwaga: Krok kompilacji można ominąć, jeśli włączona jest pamięć podręczna opcode - to znaczy, że pierwsze żądanie skryptu PHP jest przestrzegane, a powiązane z nim kody opcyjne są buforowane do ponownego wykorzystania w kolejnych żądaniach (jest to globalna pamięć podręczna współużytkowana przez wszystkie procesy podrzędne). Ponieważ etap kompilacji jest drogi (parsowanie skryptu itp.), W przypadku systemów produkcyjnych najlepiej jest włączyć pamięć podręczną kodu opcode.

  6. Po zakończeniu działania skryptu PHP przechodzi on do procedury czyszczenia (wbudowanej w DSO PHP) i wyczyści pamięć na żądanie, zamknie wszystkie opisy plików wraz z uchwytami db (w zależności od tego, w jaki sposób jest otwarty). Niektóre metody PHP mają "trwałe" uchwyty (np. Otwierające połączenia db, uchwyty plików), które mogą być przechowywane pomiędzy żądaniami, stąd ta funkcja, której używasz do otwarcia określonego zasobu ma znaczenie (co podkreśla jego odpowiednia dokumentacja). Domyślnie większość zasobów jest przechowywana w czasie trwania żądania PHP i są one niszczone po zakończeniu żądania PHP.

    Odnośnie do obiektów PHP, wszystko zależy od zakresu, w którym obiekt jest tworzony. Tak więc w przypadku obiektów globalnych jego lekarze będą wywoływani tylko na końcu cyklu żądania, podczas gdy niektóre z nich będą wywoływane, gdy wykroczą poza zakres, gdy funkcja zwróci.

    Dzięki temu otrzymujesz darmową pamięć/zasoby MGMT. Możesz kontrolować go poprzez wywołania unset(), natychmiast wyzwalając free. Począwszy od PHP 5.3, odśmiecanie może być również włączone podczas fazy obsługi żądania - więcej szczegółów tutaj: http://www.php.net/manual/en/features.gc.php

  7. Teraz to dziecko Apache (które uruchomiło skrypt PHP) powraca do puli procesów gotowych do obsługi kolejna prośba jak w punkcie 3.

co opisałem powyżej jest typowy dla Apache/PHP w środowisku Linux/Unix, ale myślę, że coś podobnego jest prawdziwe dla Microsoft Nastawienia też.

Również z nginx i FastCGI + PHP, myślę, że ten sam cykl jest prawdziwy - tzn. Rzeczy są czyszczone pod koniec cyklu żądania, który obsługuje moduł PHP + FastCGI. Także tutaj, gdy uruchomi się nginx, uruchomi pulę oddzielnych procesów obsługiwanych przez moduł FastCGI + PHP, a komunikacja między nginx i FastCGI + PHP nastąpi w gnieździe unixowym.

Mam nadzieję, że to pomoże.

+3

+1 Doskonała odpowiedź i chciałbym nieco rozszerzyć na trwałe połączenia. Proszę przeczytać ** [this] (http://stackoverflow.com/questions/23432948/fully-understanding-pdo-attr-persistent/23480158#23480158) ** po więcej szczegółów. – MonkeyZeus

5

To nie jest PHP, ale serwer WWW, który obsługuje żądania. PHP nie działa samodzielnie. Jeśli strona zawiera kod PHP, takie żądanie jest delegowane do PHP przez odpowiedni moduł PHP SAPI. Istnieją wielowątkowe, wieloprocesowe serwery WWW i można nawet wyobrazić sobie pojedynczy serwer WWW, więc jest to zależne wyłącznie od serwera WWW, jeśli zostanie utworzony osobny wątek lub proces dla żądania.

W wielu miejscach dokumentacji PHP można spotkać linie jak ten na umask():

Należy unikać stosowania tej funkcji w serwerach wielowątkowych. Lepiej jest zmienić uprawnienia do pliku przy pomocy polecenia chmod() po utworzeniu pliku. Użycie funkcji umask() może prowadzić do nieoczekiwanego zachowania się skryptów i samego serwera WWW, ponieważ wszystkie one używają tego samego umask.

... jak długo wątek pozostaje żywy? Czy ten wątek poprawnie utrzymuje wszystkie zmienne statyczne? (jak połączenie DB)

Brzmisz jak jeden z C++. Prawdopodobnie masz na myśli zmienne globalne w PHP. PHP ma wbudowaną obsługę połączeń z bazami danych i nie powinieneś się o to martwić. Są to szczegóły implementacji. Większość SAPI zapewnia stałe połączenia z bazą danych, ale to tylko dla twojej ciekawości. Stałe połączenia są tworzone po jednym dla każdego procesu, który obsługuje żądania. Tak więc w tym przypadku są one utrzymywane raczej przez proces niż wątek.

Kiedy ten wątek zostanie zniszczony, wywołuje wszystkie destruktory?

W PHP destruktory są wywoływane po zakończeniu wykonywania skryptu. Z punktu widzenia programisty PHP nie ma znaczenia, gdzie znajduje się skrypt.

+1

Powtarzasz "serwer internetowy". Wiem, co masz na myśli, ale uważam, że "serwer aplikacji" jest tutaj dokładniejszy. [ref] (http://stackoverflow.com/a/936257/418413) – kojiro

+1

@kojiro cóż, tak właśnie stały się serwery internetowe, ale OP prosi o żądania HTTP, więc myślę, że "serwer internetowy" pasuje lepiej. Tak też nazywa się PHP manual. – doc