Különítsd el webalkalmazásod publikus részét
A PHP fejlesztőket megcélzó Rails blogot már többször is elővettük a Weblabor hasábjain, nemrég PHP to Ruby Reference ötletüket blogmarkoltuk, ahol több tucat PHP-ben megismert függvény Rails alatti használatát mutatják be a készítők. A Rails for PHP programmers legutóbbi bejegyzésében – melynek tartalma a vele egybecsengő nevű könyvben kerül bővebb kifejtésre – arra hívja fel a figyelmet, hogy webalkalmazás fejlesztés során csak azokat az állományokat tegyük a webszerveren keresztül láthatóvá, amelyeket tényleg szükséges, hogy a kliens elérhessen; konfigurációs fájlokat, önállóan nem meghívott kódkomponenseket stb. helyezzük a wwwroot fölé.
Noha a tanács banálisnak tűnhet, rendre lehet találkozni olyan megvalósításokkal, amelyek ennek a megfontolásnak nem tesznek eleget. Ezzel pedig elkerülhetők lennének olyan baklövések, amelyek egyike friss élményem. Az érintett személy PHP fájlok szerkesztésére használt (szerver oldali) editora
■ Noha a tanács banálisnak tűnhet, rendre lehet találkozni olyan megvalósításokkal, amelyek ennek a megfontolásnak nem tesznek eleget. Ezzel pedig elkerülhetők lennének olyan baklövések, amelyek egyike friss élményem. Az érintett személy PHP fájlok szerkesztésére használt (szerver oldali) editora
.php~ kiterjesztéssel szorgosan biztonsági másolatot készített a megváltoztatott állományokról – persze ugyanabban a könyvtárban. A .php~ fájlokat a webszerver – egyéb intézkedés híján – sima szövegként kiszolgálta, így a config.php módosításakor jó eséllyel annak tartalma config.php~-ként elérhető volt az érdeklődők számára. Természetesen megfelelő kiszolgáló oldali beállításokkal, helyes biztonsági mentés módszertannal stb. ez nem fordulhatott volna elő, de – akár ezek hiányában is – ha a konfiguráció nem lett volna nyilvános útvonalon, most nem lenne apropója ennek a bejegyzésnek.
kedvencem
Üdv,
Felhő
enyim
Vannak durvábbak
egy htaccess
Japp
terhelés
OFF: Nómális?
minden kéréskor fel kell dolgozni
Nyilván ha nincs más választásod, akkor használod, de ha teheted, akkor célszerű vhost konfigba áttenni a dolgokat és kikapcsolni. Apró szopás van vele, mert a mod_rewrite rule-ok kicsit másképp működnek (belefutottunk egy apache bugba, azt hiszem ilyenkor nem a docroothoz képest kezelte a hivatkozásainkat, hanem a filerendszer rootjához képest), meg van egy PHP bug is: a $_SERVER['SCRIPT_NAME'] nem jól állítódik be (http://bugs.php.net/bug.php?id=38141).
Üdv,
Felhő
nyilván ez a...
Szolgáltató, Apache
Másrészt ahol tényleg számít a terhelés, ott szerintem már kezdik hanyagolni az apache-t.
Apache - terhelés
Üdv,
Felhő
Korábban volt
A Facebook vagy Yahoo meg elég sarkított példa, hozhatnék példának több nagyobb oldalt, ahol lighttpd-ről megy a dinamikus tartalmak kiszolgálása. Mi is azért tértünk át sok helyen Lightyre, mert gyorsabb. Hozhatnék példának egy olyan 3 Ghz-s P4-s gépet, ami pont azért nem lett még cserélve, mert elbírja a nagyobb tüskéket a kérések számában (rajta hostolt oldal jellegéből adódóan vannak ilyenek). Apache-l már a normál terhelést se biztos, hogy megbízhatóan kiszolgálná.
Na de ezzel befejezem az offtopicot.
facebook relatíve új dolog
Én nem vagyok rendszergazda, így ilyen témában teljes biztonsággal nem mernék állítani semmit, viszont a fentit tapasztalom általában. Szerintem itt arról lehet szó, hogy dinamikus tartalom esetén már nincs akkora előnye a lighttpdnek, viszont pl. apache meg funkció gazdagabb. Igazából nem is a gyorsaságra reflektáltam, hanem arra, hogy "kezdenek leszokni az apache-ról".
Üdv,
Felhő
Pontosítok
Látom, félreértettük egymást. Arra gondoltam, hogy az Apache egy régi jól bejáratott fogalom, sokaknak a webszerver egyenlő a LAMP-al. Szerintem nyílt forráskódú körökben is jellemző valamennyire ez a "bebetonozódás".
Igen, de két dolgot jegyeznék meg: egyik, hogy nem írtam, hogy milyen tartalom kiszolgálásáról volt szó (gondolom nem véletlen, hogy a Youtube és a Wikipedia is használja). Másik, hogy nálunk - főleg, mikor tüske van a kérésben - legelőször az index.php kapja a terhelést, csak utána szedi a statikus részét az oldalnak - ha még nincs cachelve.
Torrent oldalak jelentős része valamilyen alternatív böngészőről megy. Hozhatnám példának az egyik legnagyobbat, a The Pirate Bayt is. Ezek közül nem egy használ PHP alapú backendet, ott viszont csak dinamikus tartalom van. De például az egész Sourceforge.net is Lighttpd-ről megy.
Persze, maga a web-szerver nem teszi gyorsabbá a PHP értelmező futását, ez tény. Ha azt nézzük a FastCGI még valamivel lassabb is, mint a mod_php, előnye is abból adódik a Lightynek, hogy egyszerűbb böngésző (persze a FastCGI-nek vannak egyéb előnyei is, de ez most más kérdés). Funkciógazdagság meg megint egy olyan téma, hogy van-e rá igény. Ha viszont nincs igény a plusz funkciókra (sokan pl. ezért maradtal 1.3-s Apache-nál is), akkor szerintem egyszerűbb egy szoftverre bízni az egész oldalt, mint több különbözőre (feltéve, ha nincs rá valami külön indok).
Persze, én se azt írta, högy tömegesen migrálnak az Apache-ról, hanem arra, hogy ahol van igény a nagyobb teljesítményre, ott egyre inkább előjön az, hogy valami alternatívát keresnek.
Szezon vs...
Tényleg..
Az Apache 2.2 dinamikus teljesítményben a Lighttpd felett van.
Ezen fórum bejegyzésben is láthatod, hogy a legújabb Apache 2.2 már rég túlteljesít mod_php használata esetén a Lighttpd FastCGI megoldásán. Igen, régen még ez vésődött belénk, hogy az Apache 1.3 az gyorsabb, mint a 2.0, és aztán a Lighty meg méginkább, csak aztán dolgoztak a fiúk. Célszerű megnézni mindíg a legújabb stabil verziókat, hogy mit tudnak, mi változott. Látható volt ez a PHP4 vs PHP5.0 vs PHP5.2 nyomon is.
Nálunk bent is a teljesítmény számít, és bizony a rendszergazdák statikus tartalom kiszolgálására Lighty-t, PHP-k számára pedig Apache 2.2-t javasoltak.
aktualitás
Üdv,
Felhő