PHP multithreading in še kaj

Ta tema je nekje med programiranjem in administracijo strežnikov... rabim strokovnjake obojega :)

Iščem rešitev za PHP multithreading (MT v bodoče), ki je učinkovit oz. je približno podoben pravemu MT. Malo raziskujem, ampak mi manjka nekaj znanja na administracijiskem koncu.

Rešitev za simulacijo MT v PHP je kar nekaj (1,2,3,4,5).

Vseeno, kolikor jaz razumem, to ni v resnici multithreading ampak je forking. Kaj točno je razlika z vidika strežnika?

Je sploh možno v PHPju imeti kontrolo nad več različnimi procesi na strežniku?

Če bi vi potrebovali MT in skalabilnost neke aplikacije, bi za vsako ceno šli na drugo (Java) platformo?

Je kdo že implementiral kaj temu podobnega?

PS. še tole, funkcija proc_open... kakšen 'proces' se dejansko pojavi na strežniku ob uporabi te funkcije?

Hvala!

Po branju tega članka, mi je PHP forking jasen, zato malo spreminjam vprašanje glede tega.

Torej forking pomeni spawnat child procese, ki potem vsak lahko izvaja svoje naloge. Parent process med tem lahko čaka da končajo in potem tudi veš uspešnost zaključenih childov. Rešitev je dokaj simple, nevem pa kaj pomeni iz vidika performans ali so procesi childi nekege drugega, ali pa so to dejansko 'pravi' različni procesi?

Definitivno je neka slabost forkinga, sicer ne bi bilo toliko govora o tem da PHP ni MT.

Sry za spam.. še nekaj sem odkril: executanje procesov preko CLI

To pa dejansko naredi nov proces, ampak verjetn moraš potem imeti fully working php skripto, da jo zaženeš. To deluje če laufa PHP pod apachejem?

Zivjo.

Jaz resim multi threading tako, da pac v ozadju odprem se eno instanco skripte --> lahko preko fsockopen, curl, ...

Dela super.

fork pobere veliko več resursov kot thread, saj je v bistvu to spawnanje novega procesa, kar pomeni da dobi nov pid, ima svoj memory space, medtem ko thread tega nima. Kreiran je virtualno, veliko manj časa porabi za spawnanje/ubijanje/obdelovanje podatkov, ne dostopa direktno do OS-a ampak do aplikacije same. Skratka, forking je slaba verzija multithreadinga. Če imaš namen spawnati ogromno "threadov/forkov" kar je načeloma poanta multithreadinga/multiprocessinga se boš moral poslužiti drugega programskega jezika. PHP ima to slabo zrihtano, niti ni namenjen temu.

OK, v bistvu se gre samo za problem skalabilnosti. V primeru, da uporabim curl_multi funkcije, zato da vzporedno delam requeste na neke sajte naprimer. To ni multithreading ampak sigurno deluje brez problema, zanima me, kako to potem skalirati. Naprimer da se pojavi potreba, da je teh requestov par tisoč na par minut? Je možno to 'strežniško' nadgrajevat, da bi to pelal?

Curl je multithreading in ne spawna posebnih procesov za izvajanje... Raje povej koliko hkratnih threadov rabiš za en request in koliko ljudi bo naenkrat gor, ne koliko na par minut, to ni merilo... Načeloma pa 1000 hkratnih threadov niti približno ne bo šlo skozi... vsaj ne z cURL-om... Meni se je pri parsanju določenih stvari zataknilo tam pri 500 threadov naenkrat...

Včeraj sem testiral curl_multi, naredil 10,100 in nato še 1000 hkratnih requestov na različne sajte. Sprocesiralo se je v 10, 16, 38 sekundah. Iz mojega 5 let starega laptopa, in siolove 4mb linije.

V bistvu zadeva ni mišljena sploh tako, da bodo ta procesiranja direktno prožili uporabniki. Oni bi jih naprimer dajali v queue na magar drugem strežniku. Ta strežnik, pa bi imel potem nalogo samo sprocesirat 'čimveč' v čimkrajšem času, toliko da še pelje. Sam bi naprimer določil, koliko mu rata narest naenkrat. Upam da nisem zabluzil. Veš kaj mislim?

Razumem. Potem to načeloma ne bi smelo biti prehudo. Drugače pa še vedno lahko več instanc tega programa nardiš, pa "load balancing" :)) tko da to bi šlo.

aja pa še neki... pazi da pametn timeout nastavljaš, čene traja predolgo... tle lahko zreduciraš izvajanje za ogromno. po defaultu ne vem kolk je, ampak velik preveč.