Sens multiwątkowości w PHP Opcje

[Skie]

Witam,
ostatnio dużo mówi się o multiwątkowości/multiprocesowości w PHP - pthreads , pcntl - i tym podobne pomysły. Ludzie debatują czy PHP jest thread-safe czy też nie.
Nie potrafię zrozumieć jednak sedna tego problemu - sensu istnienia tego mechanizmu. Jeżeli wykorzystujemy klasyczną architekturę do wtorzenia serwisu - tj serwer HTTP, który wywołuje w cmd parser PHP i potrafi to robić asynchronicznie , to czy w tym momencie architektura nie staje się multiprocesowa? Po co do tego dokładać jakieś rozgnieżdżenia procesu po stronie skryptu PHP ?
Może ktoś mi to wytłumaczyć LUB wskazać literaturę/artykuł gdzie jest omówiony sens tego zagadnienia z szerszej perspektywy niż tylko parsera PHP ?

[Skie]

Nie bardzo wiem o co chcesz zapytać. Czy o wielowątkowość/wieloprocesowość po stronie serwera obsługującego żądania, czy też o skrypty użytkownika. Jeżeli chodzi o skrypty to potrzeby są takie same jak w innych językach: potrzeba przetwarzania równoległego/współbieżnego.

TEORIA:
Pytam o wielowątkowość w PHP, a nie w serwerach HTTP. Jeżeli ten ostatni dostaje 5 zapytań od 5 użytkowników, to uruchomi 5 instancji PHP, które będą pracować równolegle jako osobne procesy. Mamy w ten sposób zrealizowaną multiprocesowość architektury naszego serwisu bez wprowadzania tej możliwości w składnię języka. I proszę tutaj nie pisać o ustawieniach Apache o min i max ilości instacji PHP, o asynchronicznym czy synchronicznym sposobie przetwarzania danych etc. bo jest niezwiązane z tematem.

Rozumiem sens wielowątkowości w innych językach np C++ czy JAVA ale tutaj mi to po prostu nie pasuje. Tradycyjna aplikacja desktopowa przy uruchomieniu jest ograniczona do jednego procesu. Może nas to nie zadowalać, np przy wymagajacych obliczeniach, więc wprowadzamy obliczenia równoległe. Nie możemy jednak PHP traktować tak samo. PHP pełni rolę zbliżoną do workera w systemie multiagentowym, gdzie routerem jest wspomniany wcześniej serwer HTTP. Nie projektuje się takich systemów tak, by worker jeszcze rozwidlał swoją pracę na parę procesów.

PRAKTYKA:
Odrzućmy jednak teorię i zastanówmy się nad praktycznym zastosowaniem podziału pojedynczego procesu PHP na podprocesy wewnątrz plik *.php. Kiedy może to się przydać? Jedyne przypadki jakie przychodzą mi do głowy to:

1. Wykonanie kodu w czasie oczekiwania dostępu do magazynu danych (baza danych, cache, HDD) - można wyeliminować ten problem korzystając z asynchronicznych zapytań lub eventów.

2. Wykonywanie w tle kodu PHP niezwiązanego z danym requestem (zarządzenie serwisem, zdarzenia czasowe) - jeżeli nasz system sprawdza przy requeście czy coś trzeba takiego zrobić , to problem leży w jego architekturze i stanowi moim zdaniem poważną lukę. Nie do tego są requesty by wykonywać w ich czasie (procesie jednego requesta) takie rzeczy.

3. Kod niezwiązany z requestami, np program działający w tle niezależnie od serwera HTTP - PHP nie jest językiem, w którym powinno się implementować takie rzeczy

4. Podział kodu, który należy wykonać w requeście na niezależne od siebie części i wykonanie ich równolegle - jest to jedyne zastosowanie, które można uznać na pozór za sensowne. Zagłębajac się jednak głębiej w ten podpunkt łatwo dojść do wniosku, że serwer nieobciążony przez sieć zadziała wystarczająco szybko "1 process per request", a w przypadku coraz większego obciążenia na sieci takie rozwidlanie coraz bardziej traci sens, bo serwer i tak nie będzie miał zapasu mocy obliczeniowej, które mógłby zaoferować.

ZAAWANSOWANE ROZWIĄZANIA:
Wieloprocesowość może przydać się w nowocześniejszych rozwiązaniach - np websocket. Tutaj parę procesów może mieć sens, ale tworzyć je powinien nie kod PHP, tylko jakiś serwer socketów, który odpowiednio przekaże dane do PHP. Czyli wciąż sprawa będzie wyglądać podobnie jak przy HTTP bez znacznia, czy serwer będzie tworzył procesy PHP na stałe (np 1 na wątek procesora serwera) przy uruchomieniu czy może tworzył instancję dynamicznie dla każdego requesta. Komunikacja między nimi też będzie raczej odbywać się przez sockety.

Podsumowując, wieloprocesowość w PHP moim zdaniem nie ma sensu. Nie potrafię znaleźć ŻĄDNEGO zastosowania gdzie by to było przydatne. PHP pełni rolę workera i podział mocy obliczeniowej na procesy/requesty/zdarzenia powinna być realizowana przez serwer komunikacji napisany w języku przeznaczonym do tego zadania - tak to widzę.

Czy jestem zatem coś czego nie dostrzegam? Coś co mi umknęło w moich rozważanaich i przemawia za sensem istnienia wieloprocesowości w PHP?
Proszę o rzetelne odpowiedzi, bez wycieczek personalnych.
Będę bardzo wdzięczny (IMG:style_emoticons/default/smile.gif)

Ten post edytował Skie 14.03.2014, 21:23:30

[mls]

3. Kod niezwiązany z requestami, np program działający w tle niezależnie od serwera HTTP - PHP nie jest językiem, w którym powinno się implementować takie rzeczy

Rozwiń swoją wypowiedź. Bo ja nie widzę problemu w wykorzystaniu PHP do zastosowań dalece odbiegających od "tradycyjnych" (czyli, idąc Twoim tokiem rozumowania, wykonywanych pośrednio przez serwer HTTP).