XCHAOS:
tak určitě existuje i jiná odpověď, než mlčení nebo fantasmagorie - to urcite existuje. Ale musel bych se bavit s nekym, kdo vi, o cem mluvi. V tvem pripade jsou jen tyhle dve moznosti a ty sis zjevne vybral fantasmagorii. Tedy, pro tuhle otazku. Pro vsechny ostatni otazky a problemy, o kterych jsem psal, sis vybral trapne mlceni 8))
webové aplikace si spustí víc procesů tak jako tak, takže víc jader využijí. - pokud se bavime o nahrade PHP, tak mas nejakej Apache, kterej se stara o paralelismus na urovni jednotlivejch http requestu a pro kazdej request pak pousti, patrne pres mod_php, vlastni skript, kterej vygeneruje stranku. Cili paralelismus mezi jednotlivejma requestama mas vyresenej apachem a nemusis se o nej starat nejakym vlastnim jazykem. A k cemu je to tvoje "paralelni zpracovani kontejneru" pri zpracovani jedne stranky? K nicemu. Typickej webovej server je IO-bound, zejmena server, napsanej a provozovanej clovekem, kterej "pise v PHP a nema moznost nasadit si to na vlastni server". To je proste nejakej diskuzak, stranky nejakyho obchodu, tak neco. A ten server typicky proste vetsinu casu ceka na fileystem nebo databazi a tim, ze "spustim thready na kolekci" nic podstatnyho neziskam. Nastuduj si Amdahluv zakon 8)))
občas se zpracovávají skutečně velká data.. LOOOL. V PHP? No jasne. Akorat ze kdyz zpracovavas opravdu velky data, tak je fakt nezpracovavas v kontextu toho serveru, ale mas nekde nejakej worker proces, idealne na dedikovany masine a ten web server pak jenom sahne pro vysledek a posle ho klientovi. Takze zase, ten server je io-bound, ne cpu-bound. A jestli mi budes vysvetlovat, jak strasne se pletu, tak v kontextu toho, co me poslednich par let zivi to bude s prehledem nejsmesnejsi vec, cos v nasi debate kdy udelal 8))))
využít všechna jádra pak znamená, že to doběhne dřív - zase, idiot nechape, ze nema smysl optimalizovat veci, ktere se nevyplati. Podivej se na tuhle nyxovou stranku. Hadam, ze kdyz nejede z cache, tak minimalne 90% casu se pri jejim generovani stravi cekanim na IO, spis jeste vic. A z tech par zbejvajicich procent, na co by se tak dalo pouzit to tvoje "paralelni zpracovani kontejneru"? Mozna na formatovani jednotlivejch postu? Ale stejne to pak musis slozit dohromady, plus rezie distrubuce prace mezi thready... takze ve vysledku, i kdyby to nahodou fungovalo, usetris sotva par procent. A vlastne ani to ne, protoze na ten server ti pristupuje vic lidi a jader mas jen par, takze je vlastne uplne jedno, jestli je vytizis paralelnim zpracovanim postu pro jednoho cloveka, nebo paralalenim zpracovani requestu pro vic lidi. Ne, vlastne to neni jedno, tvuj pristup je pitomejsi, protoze paralelizace requestu uz je davno vyresena v apachi a nemusim se o ni starat, zatimco paralelizace zpracovani jednoho requestu je slozita, dost error-prone prace navic. Takze fail 8)))
Hele, tak mi nejaky konkretni priklady serveru, ktere by vyuzily to co hlasas. To znamena musi bejt napsanej v PHP, jeho provozovatel nema pod kontrolou server a deploynout muze ciste jen par skriptu, je to CPU-bound, takze preklad do C pomuze a navic je to takovej problem, kde se dobre uplatni "paralelni zpracovani prvku kontejneru" jako jedinej podporovanej druh paralelismu. Jo, a je to server, na kterej pristupuje jen par lidi a je tak zatizenej, ze casem budou chtit prekladat do C a zaroven nebou chtit prejit na pricetnou archikteturu s worker nodama... 8))) Prosim, napis par takovej prikladu. Psal jsi, ze takovejch lidi je "ne zrovna malo", tak prijit s konkretnima prikladama by nemel bejt problem, ne?