suPHP - spouštění php skriptu pod UID skriptu (diskuse)

[rADOn]

nemusi pak ale apache bezet pod rootem ?

[Michal Fecko]

nemusi pak ale apache bezet pod rootem ?

IMHO nie.

[vatamer]

Nic jsem neměnil, ale ps aux | grep apache, hlásí, že jeden daemon běži pod rootem

root     15121 16.0  7.5  31628 24236 ?        Ss   14:28   0:00 /usr/sbin/apache2 -k start
www-data 15124  0.0  7.3  31628 23712 ?        S    14:28   0:00 /usr/sbin/apache2 -k start
www-data 15125  0.0  7.3  31628 23712 ?        S    14:28   0:00 /usr/sbin/apache2 -k start
www-data 15126  0.0  7.3  31628 23712 ?        S    14:28   0:00 /usr/sbin/apache2 -k start
www-data 15127  0.0  7.3  31628 23712 ?        S    14:28   0:00 /usr/sbin/apache2 -k start
www-data 15128  0.0  7.3  31628 23712 ?        S    14:28   0:00 /usr/sbin/apache2 -k start

[azurIt]

to vzdy

[Hanička]

zrovna včera jsem suphp dala na svůj server, mám dvě připomínky... 1) mod_php není nutno zakomentovat, lze pak pro určité adresáře či složky suphp vypnout a používat modul. 2) suphp pak vlastně php skripty pouští přes cgi rozhraní, takže (u mne) to děla tak 25-30ms navíc.

[azurIt]

presne tak, funguje to cez php-cgi a to je teda velka nevyhoda. znacne to spomaluje (teda absolutne nevhodne pre mass hosting) a taktiez nie vsetky skripty s tym funguju bezproblemovo (mam skusenosti, ze napr. Joomla ma problemy).

[vatamer]

No a myslíte, že pro řešení sepsaného problému existuje elegantnější řešení jak suPHP? Jestli jo, tak aspoň naznačte, kterým směrem se ubírat :)

[azurIt]

praveze (a bohuzial) dostatocne dobre riesenie neexistuje :(

[phero]

kernel-level virtualization? V kazdym virtualu vlastni lehky web server s mod_php/fast_cgi ...

[azurIt]

tak to by bolo po vykonnostnej stranke este horsie ako suPHP ;)

[phero]

neřekl bych

[azurIt]

ja teda ano, uz vidim ako na tom rozbehas 500 webov (co by si na jednom serveri s klasickym PHP prevadzkoval bez vacsich problemov).

[vatamer]

Minimalne to bude o hodne narocnejsi na operacni pamet a to jak operacni tak i spravcovou :) Imho je to kanon na vrabce. SuPHP bych se na mass hostingu vubec nebal

[Jardík]

Ano. Lighttpd. Pro každé stránky spustíte zvlášť démona v chrootu a poté jednoho na portu 80, který přes mod_proxy kontaktuje ty ostatní např. podle domény. Ale je to docela náročné na správu (v každém chrootu vlastní php + závislosti, ale vejdete se do 10 MB na "vhost").

Není to můj nápad, ale nápad "cx".

[azurIt]

pozri toto vlakno

[vatamer]

Hm a nároky na operační paměť?

[xm]

suPHP je pomalý bazmek, mnohem lepší je správně nakonfigurovat klasické FastCGI.

[vatamer]

suPHP pomalý bazmek? Zajímavé, že jsem si toho nevšil...a FastCgi umožňuje to co suPHP?

[azurIt]

kolko webov ti na tom bezi ?

[xm]

suPHP skutečně je _extrémně_ pomalý bazmek. Podle mých testů je cca 10x - 16x pomalejší (podle druhu nasazení) než řešení s pomocí FastCGI + suExec, které je navíc mnohem flexibilnější. Prostě suPHP nebrat, je to hnus který by měl zemřít ošklivou smrtí.

[al-Quaknaa]

Už jsem to tu řešil, můžeš použít FastCGi se SuExecem a wrappery (to ti umožní i provozovat vedle sebe PHP4 a PHP5, i když PHP4 už patří do koše, spíš je to zajímavé na testování CVS PHP6), nebo, a to je podstatně jednodušší, mod_ruid. Vygoogli si to, jenom bacha na mpm-worker, jak popisuju tady, už se to delší dobu chystám postnout sem, ale nějak jsem se k tomu nedostal, zajímaly by mě totiž i vaše komentáře, snad brzo ...

Snad to pomůže vyřešit daný problém, jinak podle vlastních testů je suPHP asi 15x pomalejší než mod_php s mpm-worker a asi 10x pomalejší než mod_php s mpm-prefork nebo s řešením FastCGI/SuExec, takže bych se ho na mass hosting určitě dost obával :/