Jak to wygląda w 2022, które podejście jest najpopularniejsze? Nie jestem za bardzo into PHP ale z tego co widzę to większość rozwiązań dalej opiera się o spawnowanie wątku/procesu przez jakiś master server a PHP jest w zasadzie skryptem uruchamianym przez ten master server co jak zgaduję rodzi problemy z wydajnością jak np. każdy request płaci za powolny start (choć tu widzę, że jest jakiś workaround w postaci https://www.php.net/manual/en/book.apcu.php)
0
0
Skąd taki wniosek ? Że się Da spawnowac proces, to nie znaczy ze to zachodzi, a na wielu skonfigurowanych serwerach CGI jest wręcz niedostępne.
W Apachu to od wieków jest moduł.
Trafiłeś na złe źródła.
Powiedziałbym wręcz, że od drobnych 20 lat PHP możliwość użycia w CGI nigdy nie była wykorzystywana, od czasów niepamiętnych to moduł do serwera/ów HTTP.
"Może" jakieś studenckie domowe projekciki, może pechowo trafiłeś na hinduski tutorial
0
Chodzi mi o samą idee CGI niż o konkretną implementację. Przedstawiając to inaczej mamy dwa (trzy?) podejścia:
- aplikacja stawia się sama. Piszemy sobie
main(), łączymy się z bazami, składamy logikę, wystawiamy handlery dla konkretnych protokołów (np. HTTP albo WebSockets albo gRPC). Mamy pełną kontrolę nad współdzielonymi zasobami czy otwartymi plikami. Nic nie stoi na przeszkodzie, żeby wątek requestu A pisał do pamięci, która jest używana przez request B. Stosowane chyba przez większość frameworków i języków jakie znam i używam - mieszane podejście. Wątki requestów współdzielą pamięć i dalej wątek A i B mogą się popsuć, ale całość jest magicznie sklejona np. javowe serwlety tak działają
- podejście w stylu CGI: mamy master service, który dla każdego requestu spawnuje/reużywa wątek/proces w danym języku. W tym podejściu wątek A i B jest całkowicie odseparowany od siebie i nie mogę pisać po wspólnej pamięci, bo tak to jest. Wydaje mi się, że PHP jest właśnie tu
I teraz pytanie: gdzie jest PHP?
0
Jeśli chodzi o ideę, to raczej należałoby zauważyć, że można by zrobić aplikację (serwer www), który przechowywałby dane pomiędzy żądaniami http – czyli byłby odrębną aplikacją www. Wymienione przez Ciebie podejścia są raczej rozwiązaniami technicznej realizacji procesów na serwerze, w które wpasowuje się PHP zależnie od jego implementacji w danym serwerze www. Innymi słowy implementację PHP jako aplikację przechowującą dane ogranicza standard PHP i HTTP. Więc 3. podejście jest realizacją PHP, ale nie nazywałoby się to CGI, lecz realizacją żądań http. Zauważ, że PHP jest tutaj językiem pojedynczej strony www, a nie wymienioną na początku aplikacją www.
0
spojrzałem na szybko na kilka najszybszych wyników php w tym benchmarku https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite i te najszybsze frameworki php raczej nie odpalają nowego procesu per żądanie, a raczej odpalają event loopa jak w node.js. przy czym zaznaczam, że sprawdziłem te frameworki baaaaaaaardzo pobieżnie.
1
slsy napisał(a):
- podejście w stylu CGI: mamy master service, który dla każdego requestu spawnuje/reużywa wątek/proces w danym języku. W tym podejściu wątek A i B jest całkowicie odseparowany od siebie i nie mogę pisać po wspólnej pamięci, bo tak to jest. Wydaje mi się, że PHP jest właśnie tu
I teraz pytanie: gdzie jest PHP?
Generalnie 3.
Dzieki temu PHP 20 lat temu wygrało z Perlem :-)
Ale to było dawno temu - jak to obecnie działa nie mam pojęcia.
1
overcq napisał(a):
. Innymi słowy implementację PHP jako aplikację przechowującą dane ogranicza standard PHP i HTTP.
@overcq: co ma do tego http? Co jak moja aplikacja wystawia dane po gołym TCP (czy coś takiego jest możliwe?)?
Inne pytanie na boku: w jaki sposób PHP obsługuje inne protokoły np. wspomniane gołe sockety TCP albo w jaki sposób mogę konsumować wiadomości z kolejek np. RabbitMQ?
overcq napisał(a):
Więc 3. podejście jest realizacją PHP, ale nie nazywałoby się to CGI, lecz realizacją żądań http.
A jak nazwałbyś realizację żądań http w podejściu no. 1?
overcq napisał(a):
Zauważ, że PHP jest tutaj językiem pojedynczej strony www, a nie wymienioną na początku aplikacją www.
Widziałem serwisy w HTTP implementujące REST API, więc nie wiem o co chodzi z tą pojedynczą stroną
0
. Innymi słowy implementację PHP jako aplikację przechowującą dane ogranicza standard PHP i HTTP.
@overcq: co ma do tego http? Co jak moja aplikacja wystawia dane po gołym TCP (czy coś takiego jest możliwe?)?
Chodzi mi o to, że mechanizmy obsługujące na przykład sesję zostały zrobione na warstwie pojedynczych żądań, a nie są obsługiwane bezpośrednio.
Inne pytanie na boku: w jaki sposób PHP obsługuje inne protokoły np. wspomniane gołe sockety TCP albo w jaki sposób mogę konsumować wiadomości z kolejek np. RabbitMQ?
Funkcjonalności te są ograniczone jednorazowością skryptu.
Więc 3. podejście jest realizacją PHP, ale nie nazywałoby się to CGI, lecz realizacją żądań http.
A jak nazwałbyś
realizację żądań httpw podejściu no. 1?
Dedykowaną aplikacją www. Wtedy nie byłoby ograniczeń PHP, ale to jest poza jego standardem, tzn. nie jest opisane, jak taka aplikacja mogąca przechowywać dane pomiędzy żądaniami miałaby działać.
Zauważ, że PHP jest tutaj językiem pojedynczej strony www, a nie wymienioną na początku aplikacją www.
Widziałem serwisy w HTTP implementujące REST API, więc nie wiem o co chodzi z tą pojedynczą stroną
Tylko nie robią tego wprost przez przechowywanie w uruchomionym procesie jakichś danych, lecz przez ich odczytywanie z bazy danych na żądanie.
0
Zainteresuj się jak działa PHP-FPM, FPM jest akronimem dla Fast Process Manager.
Np:
https://tsh.io/blog/php-pm-guide-getting-started-with-the-process-manager/
https://tideways.com/profiler/blog/an-introduction-to-php-fpm-tuning
^^ chociaż to już trochę stare, ale jak poszukasz to znajdziesz :)
0
To wszystko zależy od tego jak zasetupujesz swój server.
Możesz ustawić Apache'a/Nginx'a tak żeby spawnował nowy proces PHP pod request, ale od dawna można było podpiąć GI pod PHP tak żeby jeden proces obsługiwał wiele requestów.
0
Riddle napisał(a):
To wszystko zależy od tego jak zasetupujesz swój server.
Możesz ustawić Apache'a/Nginx'a tak żeby spawnował nowy proces PHP pod request, ale od dawna można było podpiąć GI pod PHP tak żeby jeden proces obsługiwał wiele requestów.
Niezależnie od podejścia mam to samo: jest jakiś nadrzędny serwer, który uruchamia mój program jako skrypt mający zamienić request na response.
Podchodząc inaczej, czy jest możliwe takie coś:
main() {
server = newHTTPServer()
Thread.run(server.handleHTTPRequests)
sleep(100s)
server.stop()
while x = stdin.input() {
print("User input from keyboard: {x}")
}
}
Czyli mogę napisać program, który stawia/zatrzymuje serwer HTTP tak jak chce. Cykl życia programu nie zależy od requestów HTTP i mogę robić to co chcę
1
slsy napisał(a)
Czyli mogę napisać program, który stawia/zatrzymuje serwer HTTP tak jak chce. Cykl życia programu nie zależy od requestów HTTP i mogę robić to co chcę
No przecież piszę Ci, że w PHP możesz sobie napisać jaki tylko program chcesz, nie musisz wcale mieć Apache'a, żeby serwować content.
Więc odpowiadając na Twoje pytanie: Tak, możliwe.
Najprostszy server TCP w PHP jaki sobie mogę wyobrazić to coś takiego. Tylko musisz mieć extension sockets włączony w php.ini.
<?php
$socket = socket_create_listen(0); // get available port
socket_getsockname($socket, $address, $port);
echo "Listening on $address:$port\n";
while ($connection = socket_accept($socket)) {
socket_getpeername($connection, $remoteADdress, $remotePort);
echo "Received connection from $remoteADdress:$remotePort\n";
}
socket_close($socket);
I żeby zrobić request to odpalasz taki kod, albo np CURLem.
<?php
$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
socket_connect($socket, '127.0.0.1', 10077); // tutaj przekaż port
socket_close($socket);
Możesz też podać jakiś swój port do socket_create_listen(), tylko wtedy musisz obsłużyć co ma się stać kiedy jest zajęty.
0
Co jest naprawdę twoim celem w tym wątku?
Wywlekasz jakieś teoretycznie mozliwe, ale nie występujące w praktyce konfiguracje, czynisz z nich twardy zarzut ... w innym punkcie wątku piszesz jakbyś chciał cracking robić (co niemożliwe).
"lekko" szwankuje czytanie dokumentacji
https://dev.to/joetancy/php-fpm-with-apache2-2mk0
https://httpd.apache.org/docs/2.4/mod/prefork.html
https://www.p4tchwork.de/apache-php-request-handling/
https://httpd.apache.org/docs/2.4/mod/prefork.html
Generalnie wzorzec preforkingu / pre-wątków / puli (np połączeń) występuje w informatyce można powiedzieć masowo, jako super-haker od forkowanie nie spotkałeś się?
slsy napisał(a):
Niezależnie od podejścia mam to samo: jest jakiś nadrzędny serwer, który uruchamia mój program jako skrypt mający zamienić request na response.
Oryginalne. Nobel.
Czyli mogę napisać program, który stawia/zatrzymuje serwer HTTP tak jak chce. Cykl życia programu nie zależy od requestów HTTP i mogę robić to co chcę
Nie możesz (w normalnych konfiguracjach)
1
ZrobieDobrze napisał(a):
Co jest naprawdę twoim celem w tym wątku?
Chcę się dowiedzieć jak to jest w PHPie, bo w nim nie piszę i się nie znam a lubię wiedzieć jak różne technologie działają. Czasami spotykam się z taką tezą, że nowoczesny PHP jest dobry do pisania backendów (jeśli się lubi) i zła infamia z przeszłości jest przesadzona. Zacząłem lekko zgłębiać temat i dla mnie to podejście z uruchamianiem kodu jako skrypt przez nadrzędny serwer to duży blocker, bo:
- im więcej warstw (tj. mój kod i moduł serwera) tym więcej do nauki i większa szansa, że coś się zepsuje.
- jak działa obsługa innych protokołów np. jak czytać wiadomości z kolejki np. RabbitMQ? Nie chciałbym, żeby moja aplikacja była stawiania w inny sposób w zależności od tego jaki protokół wspiera.
- w jaki sposób działa reużywanie połączeń np. HTTP czy do baz danych pomiędzy requestami? Jak się nie da to słabo, bo latency i procesor bardzo cierpią. Jak trzeba używać hacków nieznanych z innych technologii to słabo
"lekko" szwankuje czytanie dokumentacji
Nie rozumiem uszczypliwości, dokumentacja zazwyczaj nie powie mi, że dane rozwiązanie jest już nie modne albo, że są alternatywy.
Oryginalne. Nobel.
I tu jest problem: dla mnie jest to bardzo oryginalne, bo nikt poza PHP już tak nie robi
Nie możesz (w normalnych konfiguracjach)
I to jest super odpowiedz za którą dziękuję
0
slsy napisał(a):
- im więcej warstw (tj. mój kod i moduł serwera) tym więcej do nauki i większa szansa, że coś się zepsuje.
Znasz jakiekolwiek środowisko w tych dziedzinach lub podobnych, gdzie kod aplikacyjny zlewa się z serwerm?
Ja znam. Serwer http na arduino (1-połączeniowy).
KAŻDE inne oddziela serwer od kodu aplikacyjnego, co więcej wykonuje to w (jakiejś formie) sandboxie / jailu aby ktoś podobny nie zrobił kuku sobie i innym np klientom serwera wirtualnego.
Wyjąłem jedno zdanie z wypowiedzi, choć nie jedyne pokazuje to samo: jak bardzo z choinki spadłeś
1
ZrobieDobrze napisał(a):
Znasz jakiekolwiek środowisko w tych dziedzinach lub podobnych, gdzie kod aplikacyjny zlewa się z serwerm?
# python
from fastapi import FastAPI
app = FastAPI()
@app.get("/")
def read_root():
return {"Hello": "World"}
// go
package main
import (
"fmt"
"net/http"
)
func hello(w http.ResponseWriter, req *http.Request) {
fmt.Fprintf(w, "hello\n")
}
func main() {
http.HandleFunc("/hello", hello)
http.ListenAndServe(":8090", nil)
}
// kotlin
fun main() {
embeddedServer(Netty, port = 8000) {
routing {
get ("/") {
call.respondText("Hello, world!")
}
}
}.start(wait = true)
}
0
Zdaje się, że nie masz pojęcia o sprawach o których mówisz. Mylisz pojęcia i mieszasz język z technologią wytwarzania oprogramowania, pakietami i innymi modułami.
PHP to język jak każdy inny ma wady i zalety. Został zaprojektowany do konkretnych celów, w których sprawdza się lepiej niż w innych. Niemniej, jednak jak inne języki pozwala tworzyć takie same aplikacje mniej lub bardziej okrężna drogą.
0
hzmzp napisał(a):
Zdaje się, że nie masz pojęcia o sprawach o których mówisz. Mylisz pojęcia i mieszasz język z technologią wytwarzania oprogramowania, pakietami i innymi modułami.
PHP to język jak każdy inny ma wady i zalety. Został zaprojektowany do konkretnych celów, w których sprawdza się lepiej niż w innych. Niemniej, jednak jak inne języki pozwala tworzyć takie same aplikacje mniej lub bardziej okrężna drogą.
Które pojęcia mylę? Z nazwą like CGI spotkałem się nawet w dokumentacji PHPa i zgaduję, że jest to oczywiste jak to działa i czym się różni od endpointu wystawionego bezpośrednio przez aplikację, której cykl życia wyznacza programista a nie jakiś nginx, apache czy inny zewnętrzny mechanizm odpalający wątki/procesy PHPowe
PHP to język jak każdy inny ma wady i zalety. Został zaprojektowany do konkretnych celów, w których sprawdza się lepiej niż w innych. Niemniej, jednak jak inne języki pozwala tworzyć takie same aplikacje mniej lub bardziej okrężna drogą.
I stąd ta dyskusja: też tak usłyszałem i zacząłem badać temat. I to podejście o którym mówię to spora wada w porównaniu do praktycznie wszystkiego innego co jest na rynku
0
slsy napisał(a):
Które pojęcia mylę? Z nazwą
like CGIspotkałem się nawet w dokumentacji PHPa i zgaduję, że jest to oczywiste jak to działa i czym się różni od endpointu wystawionego bezpośrednio przez aplikację, której cykl życia wyznacza programista a nie jakiś nginx, apache czy inny zewnętrzny mechanizm odpalający wątki/procesy PHPowe
Co ma język do endpointu i (ewentualnego) sposobu uruchamiania, tudzież administracji serwera www ?
Wlazłeś choć raz w dokumentację Apacha, modułów itd - czy tylko "filmik z YT"
Druga strona wątku i nadal nie wiem, co chcesz udowodnić (a czasem to karkołomne tezy, np 2w1 serwer+apliacja jest bezpieczniejsze na błędy kodu)
0
ZrobieDobrze napisał(a):
Co ma język do endpointu i (ewentualnego) sposobu uruchamiania, tudzież administracji serwera www ?
Wlazłeś choć raz w dokumentację Apacha, modułów itd - czy tylko "filmik z YT"
To, że chyba nie wiesz jak to działa gdzieś indziej poza PHP. Normalnie sposób uruchamiania to ./odpal_server, administracja serwera www nie istnieje, bo serwerem jest twoja aplikacja. Przykładowo w wspomnianym wcześniej przypadku:
// go
package main
import (
"fmt"
"net/http"
)
func hello(w http.ResponseWriter, req *http.Request) {
fmt.Fprintf(w, "hello\n")
}
func main() {
http.HandleFunc("/hello", hello)
http.ListenAndServe(":8090", nil)
}
Ostatnia linia blokuje mój program. Każdy request idący na port :8090 zostanie przeczytany przez socket wystawiony przez moją aplikację (nie żaden serwer WWW), który następnie zostanie przemielony przez bebechy biblioteki implementującej serwer a na koniec wywoła funkcję hello z odpowiednimi argumentami. ListenAndServer może obsłużyć wiele requestów na raz i będzie je obsługiwał dopóki nie poleci jakiś krytyczny błąd.
0
Ale tego nie determinuje język, tylko użyte biblioteki.
Tu masz w php server http https://github.com/amphp/http-server podobny do twoich przykładów.
0
hzmzp napisał(a):
Ale tego nie determinuje język, tylko użyte biblioteki.
Lub dla rozwiązań pracujących w kontenerze (cokolwiek by to znaczyło) - kontener
NB ten brzydki kontener może i praktycznie zawsze zabezpiecza, żeby głupi / złośliwy programista aplikacji webowe nie napisał exit();
0
Używane jest "ala CGI" bo tak jest łatwiej, szybciej, taniej. Ale nic nie staje na przeszkodzie by użyć jakiegoś kombajnu by działał jak taki np tomcat. Tylko po co? Od biedy w PHP możesz nawet zrobić GUI aplikacje wielowątkową - tylko ten język nie został zaprojektowany do tego.
0
Mi chodzi o takie podejście, gdzie mamy mechanizm nadrzędny i wątki aplikacji nie żyją we wspólnej przestrzeni adresowej — slsy 14 minut temu
Na pewno nie w wersji "bezkontenerowej", bo ktoś musi być właścicielem socketu postawionego w 'listen'
NB ten sławny CGI jest prymitywnym (w pewnym sensie) standardem, całość req htp przyjął kontener, przekierowuje pipe do procesu CGI, ten nic nie wie o kliencie / sockecie, oddaje pipą response do kontenera ... iu tak sie kręci.
Przypuszczam w Javie *) by się dało odpalić N subprocesów potomnych w izolowanych przestrzeniach, (wykładało by to singletony , cache itd) ... nigdy się nie spotkałem, aby ktoś sobie taki cel postawił.
Nikomu wątki tego samego właściciela, działające w tym samym obszarze biznesowym, ze wspólną przestrzenią nie przeszkadzają/ły
*) znam lepiej niż .NET serwery
0
Według mnie aplikacje w modelu "tradycyjnym" czyli takim z użyciem zewnętrznego serwera są jeszcze nadal najbardziej popularne bo są to aplikacje legacy, a nowe pisane są w ten sposób siłą rozpędu, ale to będzie się zmieniać. Biblioteki takie jak ReactPHP czy AMPHP pozwalają na prostą implementację mechanizmów asynchronicznych (a więc np. wydajnych serwerów), a ostatnio wprowadzone zielone wątki (Fibers) pozwalają na użycie w tym modelu rozwiniętych i szeroko znanych frameworków typu Symfony czy Laravel (a więc komp. z PSR-owymi contractami). Utrzymywanie takiej aplikacji jest w praktyce prostsze i wymaga mniejszych nakładów, trzeba się jedynie otworzyć na nowe.