Dotaz: je LAMP / PHP single thread?

[marky]

Mám jedno CMS v PHP články formátujem cez markdown hľadal som nejaký šikovný konvertor pre PHP takže som vybral tento https://parsedown.org/ akurát mi v ňom nefungovali veci nad rámec štandardu markdown napríklad pridávanie CSS classov na elementy cez {.nejakatrieda}. Vyhodil som ho teda. A upravil som jednu aplikáciu ktorá obsahuje jeden vymakaný (nephpčkový) markdown parser MarkDig. Ten má kopu rozšírení, pridal som teda do appky nový controller MarkdownController a akciu ToHtml takže teraz ten markdown parser pouzivam z PHP aplikácie cez restové api.

POST /markdown/to-html pošlem mu postom string v markdowne a dostanem json obsahujúci html.

Lenže to má jednu drobnú nevýhodu: Pristupujem z jednej domény na inú. Celý preklad z MD do HTML trvá nejaky kratky cas mozno 500 ms. lenže na tých pol sekundy vlastne zamrzne celé PHP možno dokonca aj celý apache. Keď som mal otovrený debugger tej aplikácie (ktorá poskytovala to REST api) a dal som si breakpoint na miesto kde sa prekladá markdown do HTML a začal som ju krokovať tak spolu s ňou zamzla aj tá PHP aplikácia ktorá očakávala response z rest api.

Neviem presne technické detaily ako funguje PHP (cakal som ine spravanie), ale mám dojem že PHP beží na len jednom vlákne. A a kým mi ne-php REST api nevráti response tak vlastne neni k dispozízii cela stranka? Správne to chápem? Takže asi by bolo dobré aby to neblokovalo hlavné vlákno. Keby som nebol v PHP tak by som to hodil buď na nové vlákno alebo spustil ako task, thread, TPL, thread pool, alebo pouzil backgroundworker alebo niečo podobnbé ale podporuje také niečo aj PHP? A rovnako aj posielanie emailov by malo prestat blokovat hlavne vlakno

Odpovědi

[M. Ponkrác]

Nevím jak je to dnes, ale před řadou let fungoval Apache tak, že spustil houf procesů nebo threadů. A v tomto poolu pak honil HTTP requesty.

Pár HTTP requestů tedy nemohlo zablokovat ani Apache, ani PHP, protože paralelně jich mohlo běžet větší množství.

Jinak ano, PHP je single-thread. Ale protože je většinou spuštěn x-krát v poolu, tak jeden request by to neměl mít možnost zablokovat.

Onlouvám se, pokud jsou mé informace již zastaralé, a dnes už se to dělá jinak. Už to pár let nesleduji jak se to vyvíjí.

[Kit]

PHP běží jednovláknově, ale Apache vytvoří pro každý HTTP požadavek nové vlákno (resp. si ho vezme z poolu) a v každém z nich může běžet jiné PHP. K blokování tedy nedochází.

PHP samo umí fungovat jako jednovláknový HTTP server, u kterého by k takovému problému mohlo dojít. Proto se používá jen pro testovací účely.

BTW: 500 ms na zpracování Markdownu je hodne. To je v tom celá kniha?

[Matlák]

Keď som mal otovrený debugger tej aplikácie (ktorá poskytovala to REST api) a dal som si breakpoint na miesto kde sa prekladá markdown do HTML a začal som ju krokovať tak spolu s ňou zamzla aj tá PHP aplikácia ktorá očakávala response z rest api.

Nevím jestli to chápu dostatečně ale tohle mi přijde logické - protože krokuješ překlad jehož výsledek pak vracíš, nemůžeš čekat že ta aplikace která response čeká ho nějakým zázrakem dostane s předstihem dřív, než ten překlad odkrokuješ nebo pustíš. To je tuším něco jako kauzalita.

Pokud bys to pustil asynchronně (a že je to v PHP podporované velmi mizerně) tak bys a) musel stejně čekat než se ten proces dokončí abys mohl ukončit skript a vrátit výsledek a nebo b) bys výsledek zahodil a tvé REST API by nevrátilo nic.

p.s. pomiňme teď fakt že vracet z REST služby HTML zabalené v JSON je oescapovaný hnus a že používat PHP v PHP přes REST je ještě větší hnus