Hi!
Fast cgi- ről szeretnék átállni egy szerveren modphp- ra. Az érdekelne, hogy milyen buktatói vannak az alábbi műveletnek, mire kell figyelni, kinek milyen tapasztalata van az adott dologgal. Nyílván az egyedi beállításoknál lehet a legtöbb buktató.
Rendszer: Ubuntu Gutsy, apache2.
Köszi.
- 1183 megtekintés
Hozzászólások
leginkabb a jogosultsagokat csekkold, hogy az apacsnak legyen joga olvasni, ill. szukseg szerint irni a file-okat/konyvtarakat.
t
[szerk: miert a valtas?]
- A hozzászóláshoz be kell jelentkezni
Nem én találtam ki, de állítólag hatékonyságbeli okai vannak, illetve nem elég rugalmas (???). Ezen mondjuk én is elgondolkoztam, hogy mi értelme van. Ötlet?
- A hozzászóláshoz be kell jelentkezni
a cgi ezerszer rugalmasabb szerintem. elvileg hatekonyabb es gyorsabb is, de legalabbis takarekosabb.
t
- A hozzászóláshoz be kell jelentkezni
A suphp is php-cgi-t hivja meg, mégis mikor modphp-ról váltottunk suphp-ra, akkor ~20%-os teljesítménynövekedést tapasztaltunk.
Attól lehet, hogy nem tisztán cgi-vel, hanem suphpval használjuk?
- A hozzászóláshoz be kell jelentkezni
Ha sima CGI-t használtatok, akkor annál minden gyorsabb. Ha FastCGI, akkor viszont nem értem a dolgot.
- A hozzászóláshoz be kell jelentkezni
suphp ami a /usr/bin/php-cgi -t meghívja. Suphp-t és fastcgi-t nem tudtam összehozni, mert a kettő "ütötte" egymást. Külön-külön jól mentek. ( http://hup.hu/node/52494#comment-730624 ) Lehet, hogy csak én toltam el valamit.
A cél az lenne, hogy virtualhostonként különböző php.ini-t tudjak beállítani és más-más uiddal menjen. Az utóbbi ne legyen valós UNIX user.
A suphp ezért volt kényelmes, mert 1000:apache, 1001:apache jogokkal működött a dolog. Viszont sok erőforrást eszik:(
- A hozzászóláshoz be kell jelentkezni
A suPHP-t mit megoldást elvetettük, több okból is. Egyrészt a FastCGI általánosabb (lehet vele Rubyt, Monot futtatni) és suexeckel egész jó teljesítményt produkált. Egyedül a suexecben kell az atomparanoid részt kikommentezni, hogy a futtatott fájl tulajdonosát megnézze és máris szebb a világ egy közös PHP wrapperrel.
- A hozzászóláshoz be kell jelentkezni
"A suPHP-t mit megoldást elvetettük, több okból is."
Milyen okokból?
- A hozzászóláshoz be kell jelentkezni
Egyrészt a FastCGI jobban bejáratott, jobban támogatott útnak tűnik, más részről pedig a suPHP, mint ahogy a neve is mutatja, csak PHPra volt jó. Harmadrészt amikor néztük, az volt egy pár éve, akkor kb 60x lassabb volt, mint a mod_php.
Plusz, mint utóbb felmerült, a FastCGI-t lehet LDAP-ból konfigurálni, ami nem kis fegyvertény.
- A hozzászóláshoz be kell jelentkezni
Hogy lehet a fastcgi-s (nyilván nem a sima cgi-sre gondoltál) PHP interpreter hatékonyabb és gyorsabb, mint a webszerverben futó?
Előbbinél két processz között történik adatátadás, míg utóbbinál a HTTP kérést amúgy is kiszolgáló webszerver processzben zajlik minden.
Pont, hogy elvileg ez utóbbi hatékonyabb és gyorsabb.
Nem?
suckIT szopás minden nap! Python unladen swallow teljesítmény
- A hozzászóláshoz be kell jelentkezni
Volt, aki bent a cégnél mért ilyeneket, hasonlóra jött ki a performancia. Attól függ, hogy hogy van megírva, hány vhostod van, satöbbi, satöbbi. Erre nem tudok pontos infót mondani sajnos. Akinek van kedve, mérje ki. Én per pillanat a PHP 5.3-mal játszom. :)
- A hozzászóláshoz be kell jelentkezni
Kérdés: hosting szerver vagy egy oldalt szolgál ki?
- A hozzászóláshoz be kell jelentkezni
Saját szervere a tulajnak, kb. 300 különböző oldalt szolgál ki. Gondolom utóbbira irányult a kérdésed.
- A hozzászóláshoz be kell jelentkezni
Gondolom azt szeretné, hogy szerver/memória/processzor upgrade helyett, ezzel olcsóbban megússza :)
- A hozzászóláshoz be kell jelentkezni
Nem egészen. A kérdés az, hogy az összes alkalmazást ő kezeli, vagy a userek is basztathatják. Ha a userek is basztathatják az alkalmazást, akkor a mod_php-val pl nem fogsz tudni quotázni (hacsak nem használsz MPM ITK-t vagy peruser-t. Az ITK performancia szempontjából annyira nem király, de elviselhető. Sajnos a mod_php-ra való váltással túl sok erőforrást nem fogsz tudni megtakarítani, van, amikor gyorsabb lesz, van, amikor lassabb.
Rugalmasság szempontjából nézegesd meg a mod_vhost_ldap-ot, az elvileg tud FastCGI-t paraméterezni.
- A hozzászóláshoz be kell jelentkezni