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 ?

[destroyerr]

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?

Polecam odświeżyć wiedzę na temat jak serwery obsługują php. Tak staje się wieloprocesowa lub wielowątkowa.

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 ?

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.

[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

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

[destroyerr]

Gdyby Twój pierwszy post posiadał taką treść nie byłoby "wycieczek personalnych".

Nie projektuje się takich systemów tak, by worker jeszcze rozwidlał swoją pracę na parę procesów.

Dlaczego? Jeżeli mamy do jednej maszyny przypisanego jednego workera to dlaczego nie rozdzielić go na procesy (patrz: celery).

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.

Można, ale można też skorzystać z "wątkó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.

Tutaj się zgadzam. Potrafię jednak sobie wyobrazić, że ktoś ma taką potrzebę i realizuje ją w ten sposób. Nie uważam, że PHP powinno to ograniczać.

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

Może jednak jakieś argumenty? Jeżeli cały model dziedziny mam napisany w PHP, do tego mam też komunikację z zewnętrznymi usługami to nie widzę sensu na przepisywanie tego do innego języka. Moim zdaniem to jest właśnie kluczowe miejsce istnienia wielowątkowości i wieloprocesowości w PHP.

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ć.

Nie przekonuje mnie to. Jeżeli na jednej stronie mamy do wyświetlenia dwa raporty, to wykorzystując dwa procesory odpowiedź powędruje do klienta szybciej niż wygenerowanie tych raportów jeden po drugim na jednym procesorze.

[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).

[Skie]

Nie przekonuje mnie to. Jeżeli na jednej stronie mamy do wyświetlenia dwa raporty, to wykorzystując dwa procesory odpowiedź powędruje do klienta szybciej niż wygenerowanie tych raportów jeden po drugim na jednym procesorze.

W teorii tak, ale w praktyce serwisy PHP nie wymagają twardych ograniczeń czasowych, co oznacza, że będziemy chcieli użyć w maksymalnym stopniu dostępny hardware by zminimalizować koszty utrzymania serwisu. Innymi słowy w praktyce, jeżeli zaprojetkowalibyśmy obsługę pojedynczego requesta w równoległej architekturze to i tak nam niewiela da, gdyż serwer nie będzie miał zasobób, by to wykorzystać.

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).

Różne języki programowania zostały stworzone do różnych celów. C++, JAVA, PHP, Erlang etc. Każdy z nich ma swoje mocne strony, do których powinien byc używany. Próba dodawania "brakujących funkcji" poszczególnym językom na siłę i używanie ich w "dalece odbiegających od tradycjnych zastosowań" jest moim zdaniem pomysłem z góry skazanym na porażkę. Bo jak mówi przysłowie, jak coś jest do wszystkiego to jest do d....

Nie wydaje mi się, by ktoś jeszcze był zainteresowany tematem, gdyż wisiał tu parę dni i napisały 2 osoby. W każdym razie dziękuję Wam za opinie

Ten post edytował Skie 22.03.2014, 01:49:36

[destroyerr]

Może nikt na siłę nie chce Cię przekonywać, skoro wszystko negujesz. Masz swoją tezę i nie ma sensu jej zmieniać. Skupiasz się tylko na swoich założeniach i warunkach, które arbitralnie przypisałeś językowi PHP. Innych możliwości nie dopuszczasz, ale praktyka pokazuje, że jest inaczej.

[irmidjusz]

Haha dokładnie tak, jak mówi destroyerr Właśnie pisałem swoją odpowiedź, ale destro był szybszy.

Hej Skie, nie bierz tego personalnie, co napiszę, ale wg. mnie to istotną sprawą w tym temacie jest Twoje podejście do niego Napisałeś tekst przeciwko wieloprocesowości w PHP, bo masz o tym takie zdanie, i co - chcesz wszystkich przekonać, że w PHP to jest be i nie wolno tego robić, czy jak? Napisałeś paszkwila na wieloprocesowość z uzasadnianiem z góry przyjętych tez

Dla mnie to wygląda tak: dużo myślisz, ale mało programujesz i zamiast wypróbować jak różne rozwiązania sprawdzają się w realu, zadowalasz się tylko własnymi myślami na temat tego jak by to było, jak to może jest, co tam się powinno albo nie powinno itp. PHP ma rozszerzenia dzięki którym można pisać programy wieloprocesowe, z korzyściami charakterystycznymi dla wieloprocesowości. I to działa, tylko trzeba podejść bez uprzedzeń a priori do tematu Znam system działający w realu, który wykorzystuje w PHP wieloprocesowość i działa zaskakująco dobrze, bardzo stabilnie; te procesy nawet gadają ze sobą po socketach.

Tylko z tym co napisałeś w p. 2. zgodzę się - to by świadczyło o kiepskiej architekturze, ale od biedy jeśli ktoś tak to zrobi i takie rozwiązanie będzie przez lata poprawnie funkcjonowało i zarabiało pieniądze, to czemu nie?

Napisałeś:

Odrzućmy jednak teorię

- nic a nic nie odrzuciłeś teorii, wyłącznie teoretyzujesz, od początku do końca wszystko jest Twoimi poglądami na ten temat. Poza tym, niepotrzebnie na początku mieszasz wielowątkowość z wieloprocesowością.

W punkcie 4 piszesz o możliwościach obliczeniowych i zasobach serwera:

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

Tu są dwa ukryte błędne założenia:

1. - że serwer nieobciążony zadziała wystarczająco szybko - nie! to, co oznacza "wystarczająco szybko" określone jest przez biznes. Reuestów może nawet nie być wiele, i serwer ma dużo zapasu mocy, ale chcemy jak najszybciej odesłać odpowiedź, a przetwarzanie każdego requesta trwa zbyt długo, więc po wykonaniu niezbędnego minimum pracy forkujemy nowy proces, który wykona resztę roboty, a główny może się zakończyć i odesłać response;

2. - że przy wielu requestach zacznie brakować mocy... domyślnie: tylko w systemie wieloprocesowym. A jednoprocesowym nie zacznie? Też będzie brakowało, i to może nawet szybciej? Wszystko zależy od budowy takiego systemu, bo jednoprocesowy request trzyma wszystkie zasoby otwarte od początku do końca, gdy tymczasem rozdzielenie pracy na kilka procesów, z których każdy robi małą część roboty i zużywa mniej zasobów oraz zwalnia je szybciej, może dać ogólnie lepszą przepustowość. A może lepiej, aby niektóre procesy pracowały non-stop w tle? Nie wywnioskuje się tego w żaden sposób, można to tylko sprawdzić empirycznie w konkretnym przypadku

Próba dodawania "brakujących funkcji" poszczególnym językom na siłę i używanie ich w "dalece odbiegających od tradycjnych zastosowań"

- to stwierdzenie jest błędne bo wieloprocesowość w PHP nie jest niczym brakującym - jest dostępna i normalnie realizowana za pomocą odpowiednich funkcji z bibliotek. Te funkcje to api do możliwości oferowanych przez język C. A jeśli chodzi o "tradycyjne zastosowania" - no cóż, jeśli chcesz ograniczać swoje myślenie to proszę bardzo, Twoja sprawa, ale nie dorabiaj do tego filozofii o tym co jest dobre albo złe do zrobienia z PHP

(...)jest moim zdaniem pomysłem z góry skazanym na porażkę

- ok, każdy ma prawo do własnego zdania, aczkolwiek to jedno akurat ma mały związek z rzeczywistością Rzeczywistość weryfikuje na szczęście wszelkie dywagacje na swój temat.

[zegarek84]

ja bym rzekł inaczej gdyż temat obserwowałem a wypowiadać się nie mam raczej prawa gdyż nie jestem informatykiem ani w tym kierunku studiów nie skończyłem (jakoś teraz nie mam czasu na żeby zacząć pracę dyplomową mgr akurat a z informatyki nigdy kasy nie miałem ;p) [inż. jest ale w wykonywanym zawodzie ;p]

daaaawno temu podsuwałem rozwiązania na surowych socketach w PHP i wiele osób nawet jak dorabiałem akurat w JS mówiło mi, że to się mija z celem (jeśli chodzi o wsparcie i materiały to tak) - ale dlaczego, bo sięgałem głębszego tematu jak sockety nie blokowane czyli motyw jak w node.js gdzie pewnie to zostało dalej na jednym wątku - w PHP już dawno coś takiego mogło być tylko biblioteki albo nikt nie napisał albo nie wypromował ;p... a o symulowaniu wielowątkowości i o komunikacji na socketach do synchronizacji wspominało się...

z kolei mając styczność z C++ wymuszoną na studiach widzi się niezłe rozwiązania jak Qt czy Asio... asio to akurat surowa obsługa socketów ale też programowanie zdarzeniowe prawie jak JS, Qt świetne biblioteki + implementacja do samej biblioteki przeglądarki WebKit co jak mi na głowę zrzucili raz robotę do wprowadzania danych do jednej stronki gdzie multum js i ajax to "dziękowałem Bogu że to znam" gdyż nie musiałem pisać pluginu do przeglądarki lub siedziałbym nad obliczeniami i wprowadzaniem danych z 3 tygonie po 12h ;p - uprościłem sobie do 3,5 dnia ;] (czasem lepiej nie pokazywać co się umie gdyż moja praca nie jest związana z komputerami a polecenia przełożonych muszę słuchać ;p)...

ze swojej perspektywy stwierdzę, że dobrze iż wprowadzają multiwątkowość w PHP, nie ma sensu się rozpisywać, motyw jest podobny jak z node.js gdyż w PHP już od dawna wiele osób tworzyło aplikacje konsolowe (+ nie wiele dalej sięgnąć wzrokiem), zresztą zf2 to też wspiera ale nie miałem czasu temu się przyjrzeć ;p (jedynie mając większą wiedzę o lepsze zarządzanie pamięciom by się prosiło i o rozwiązania na smarot point w implementacji PHP).... z esencji zasięgów "closure" (domknięć nawiasów" to mało kto korzysta chyba choć jak język poznałem to to dosyć fajne, ale idąc dalej w las można by napisać, iż JS jest językiem funkcyjnym... w gdzie drwa rąbią tam wióra lecą... c++ jest wieloparadygmatowym gdzie nie raz nauka zasięgu odnosi się linkami do JS... każdy język ma swoje przeznaczenie ale jednak dobrze tworzyć coś nowego, gdyż tak było, jest i będzie... więc czemu nie usprawniać języka przez nowe rozwiązania/biblioteki (bib. czasem) jako standard?? zawsze to można wycofać...

fajnie by było, gdyby czasem ktoś rozwinął motyw asynchronichnej komunikacji w PHP po socketach, ale raczej czarno to widzę jak widziałem kiepskie rozwiązania implementacji i opisy nawet po samej implementacji biblioteki curl asynchronicznej... informatycy raczej znaleźli rozwiązania a ja nie bardzo mam czas dawać przykłady gdzie to robiłem za darmo ze zwykłego curla do połączeń asynchronicznych jakie nawet w manualu PHP nie opisali a na szczątki tylko trafiłem... przykłady mam tylko z forum i tak na prawdę z wiedzą było od wieków, zrób to i tamto "za piwko" a czasem gra nie warta świeczki... rozwiązań to już było muuuultum i wielokrotnie za gorsze bywa wynagrodzenie (sorki za wcześniejsze zdanie - ja nic ciekawego nie rozwiązałem tylko to ciężej skleić w całość, a Ci co mnie kojarzą pamiętają jak moje wypowiedzi tu się zmieniały)... zresztą idę do sklepu po następne piwko ;p - jutro dzień wolny a w poniedziałek znowu 24h służby i jak nie poleje to większość klepania trawy tłumicą ;p ;]