ugrás a tartalomhoz

LAMP: itt az alkonyat

Bártházi András · 2012. Feb. 13. (H), 10.39

A LAMP az utóbbi évekig az egyik legnépszerűbb kombináció volt, ha weblapok kiszolgálásáról beszéltünk. Ma már nem, a rövidítésben szereplő elemek közül csak a Linuxnak van bebetonozott pozíciója, de sem feltétlenül az elemeknek, a kombinációnak pedig már végképp nincs.

A LAMP betűszó a Linux, Apache, MySQL, PHP (vagy akár Perl, Python) rövidítése. Az internet térnyerésével váltak ezek a szoftverek egyre népszerűbbé, az Apache a Wikipédia szerint kulcsszerepet játszott a web terjedésében, a MySQL és a PHP pedig az egyszerű telepíthetőségével, tanulhatóságával lett igen-igen népszerű. Ha utánanézünk, talán mindegyik szoftver a mai napig a legnépszerűbb a kategóriájában, azonban (a Linux kivételével) szépen lassan feltűntek az erős alternatívák, melyek már megmutatták erejüket.

nginx

Az nginx (ejtsd: engine-x) nevével érdemes megbarátkozni. Mára a második legnépszerűbb webkiszolgáló lett az Apache mögött, a nagy látogatottságú site-ok legtöbbje már váltott rá. Gyors, kevés erőforrást eszik, és könnyen mögé lehet tenni más webszervereket is (akár Apache-ot) – kiválóan proxy-zik. PHP-t a PHP-FPM megoldás segítségével tud futtatni, talán ez a ma legjobb felállás, ha valaki PHP alapú weblapot akar kitenni a webre.

*SQL

A MySQL-ről nem mondanám, hogy vesztett a népszerűségéből, de sok megfontolandó alternatíva jelent meg mostanság. Az Oracle felvásárlás is sokakat elbizonytalanított, de egyelőre úgy tűnik viszonylag lelkiismertesen fejlesztik tovább, illetve számos alternatív és kiváló terjesztések is létezik, mint például a Percona által épített. Ha valaki MySQL-t használ, akkor érdemes például ezt választania inkább, nem pedig a hivatalos terjesztést. A PostgreSQL-ről webfejlesztői körökben viszonylag keveset hallani, de szintén egy stabil kihívó.

A NoSQL mozgalom is egyre népszerűbb. Még a MySQL-nél maradva, ehhez is készült NoSQL kiegészítő, a HandlerSocket, de még az Oracle is közzétett egy plugint, melynél a memcached protokollt lehet használni az InnoDB engine-nel történő kommunikációhoz.

Aztán ott vannak persze a méltán népszerű „valódi” NoSQL szerverek, mint például a MongoDB vagy a Redis (de még sorolhatnám), melyek vagy egy speciális szerepkörben, vagy akár a hagyományosban is képesek kiváltani a korábbi relációs adatbázisokat.

Polyglot

Ami a webfejlesztést illeti, a PHP, Perl, Python hármas közül leginkább a Perl az, ami vesztett a népszerűségéből, a másik két nyelv inkább csak növekedett, s olyan nyelvek csatlakoztak hozzájuk, mint a Ruby, vagy akár a JavaScript. Érdemes megnézni a népszerűségi listát is, mely GitHub és Stack Overflow statisztikákból építkezik. A Java és a .Net inkább a nagyvállalati alkalmazásukról híresek, de a Java nyelvi elemeiben és keretrendszer ellátottságában is közelít az előbb említettekhez, a JVM-nek pedig egyre jobb a dinamikus nyelvi támogatása (lásd pl. JRuby).

Úgy tűnik, hogy a „polyglot” (magyarul többnyelvű) szakemberek is egyre jobban előtérbe kerülnek, nem csak a programozási, de egyéb technológiákra is értve a kifejezést.

Tanulni

Érdemes utánajárni, megtanulni a fentebb sorolt technológiákat, nem csak azért, mert szükségünk lehet rá a napi munkában, de azért is, mert újabb és újabb nézőpontokat tanulhatunk meg a folyamat során, ami biztosan jobb szakemberré tesz minket.

 
1

:) valahogy a bejegyzés címe

virág · 2012. Feb. 13. (H), 11.03
:) valahogy a bejegyzés címe nincs összhangban a tartalommal... szerintem nem látni "alkonyatot", inkább csak tárház-eszköztár-bővülést, de az "alkonyat" szerintem kicsit költői túlzás.
Az utolsó bekezdésedben amit írtál az nagyon fontos.
2

pedig...

Cadeyrn · 2012. Feb. 13. (H), 11.15
... sok igazság van a LAMP végében. A Percona tényleg jobb, a noSQL viszont nem kiváltója a relációs adatbázisnak, inkább kiegészítője, szerintem. Az apache sem az ősgonosz magában, a modulok, amik szörnnyé teszik sokszor, de svn és dav támogatottság értelmesen nincs egyetlen másik webszerverben sem, szóval az apache leáldozása szerintem még odébb van.

Az nginx viszont embertelenül erős, és bőven megérdemli a helyét, ha embedded perl opcióval van fordítva, akkor meg tényleg képes megváltani a világot.
6

Apache

Bártházi András · 2012. Feb. 13. (H), 11.39
Nem célom az Apache bántása, sok olyan dolog van amit csak Apache alapokon lehet megcsinálni, és valóban jó cucc. Az nginx inkább a kiszolgálási modelljével gyűri le, mint feature listájával.
3

Kiegészítés

Bártházi András · 2012. Feb. 13. (H), 11.30
Az első bekezdés végére írtam egy kiegészítést, mely pontosít egy kicsit. Arra gondolok, hogy a LAMP együtt, mint kombináció járja a végét. Korábban ha azt kérdezte tőlem valaki, hogy mit ajánlok PHP-MySQL üzemeltetéshez, akkor a LAMP-ot mondtam, ma már az nginx + PHP-FPM kombót, és vannak esetek, amikor a MySQL-t is érdemes lehet megkérdőjelezni.
4

Épp múlt héten próbáltam ki

Hidvégi Gábor · 2012. Feb. 13. (H), 11.33
Épp múlt héten próbáltam ki az nginx-et, össze szerettem volna hasonlítani a php teljesítményét az Apache-csal. Virtuális gépen, OpenBSD alatt magam fordítottam a szoftvereket (legújabb nginx, php 5.3.10 FastCGI, php-hoz eAccelerator kiterjesztés), sajnos pontos számokra nem emlékszem, de ugyanannak az oldalnak a kiszolgálása 250ms körül volt Apache+mod_php kombóval, míg nginx + php fastcgi-vel 300 fölött (többször frissítettem).

A Perconát is kipróbáltam pár hónapja, de teljesítményben nem láttam különbséget közte és az 5.5-ös MySQL között.

Mindenképp érdemes ezeket az új dolgokat kipróbálni, mert lehet, hogy más hardver plusz operációs rendszer kombóval egészen más eredményeket kaphatunk.
5

fastcgi

Bártházi András · 2012. Feb. 13. (H), 11.37
FastCGI-vel nekem nem sikerült összebarátkoznom, pedig élesben is próbáltam, érdemes inkább a PHP-FPM-et megnézni. Hasonlítsd össze azzal! :) Nem csak a sebesség miatt a legjobb kombináció az általam javasolt, hanem például a memóriaigénye is kisebb, ha sok szál kiszolgálásáról van szó.
7

Tervben van

Hidvégi Gábor · 2012. Feb. 13. (H), 11.43
Amint lesz rá időm, mindenképp ki szeretném próbálni.

A lighttpd-ről tudsz valamit, érdemes vele foglalkozni? Állítólag eléggé leálltak a fejlesztésével.
18

lighttpd

Bártházi András · 2012. Feb. 13. (H), 15.17
Az nginx-szel ismerkedés sokkal aktuálisabb, sokkal inkább ezt ajánlom. :) A lighttpd is ugyanazt az aszinkron modellt használja, mint az nginx. A lighttpd kapcsán én csak a szívásokra emlékszem a rewrite rule-ok környékén. :)
19

Sokkal komolyabb

janoszen · 2012. Feb. 13. (H), 16.54
Sokkal komolyabb szivasok vannak a LigHTTPd-vel, pl nem kezeli az Expect: 100-continue fejlecet, aminek koszonhetoen Opera alol nem lehet normalisan filet feltolteni.
13

FastCGI

janoszen · 2012. Feb. 13. (H), 13.52
FYI a PHP-FPM is FastCGI-t beszel, csak mas a spawner. Az elobbi ugyanis sajat maga inditja a daemont (ezt a regebbi PHP-k is tudtak), az utobbi a webszerver inditja on demand, ami igazabol egy hack.

A PHP-FPM-nek egyebkent vannak mas hasznos funkcioi is.
17

FPM

Bártházi András · 2012. Feb. 13. (H), 15.09
Sőt, az FPM jelentése FastCGI Process Manager. :)
8

Érdekesség

Bártházi András · 2012. Feb. 13. (H), 11.45
Ide kapcsolódik, az 5. legnépszerűbb tartalom a Weblaboron az Apache és PHP telepítése kezdőknek Windows rendszereken című cikkünk. Kéne írni egy nginx+PHP-FPM telepítőset. :)
10

Na nézzük csak

Thoer · 2012. Feb. 13. (H), 12.30
apt-get install mysql-server mysql-client nginx php5-fpm

Na jó, csak vicc volt.

Egyébként én is pont a hétvégén szórakoztam először nginx-szel és meglepően egyszerű volt kialakítani egy olyan környezetet, hogy port számtól függően különböző php verziókat futtasson. Más kérdés, hogy a PHP builddel megszenvedtem, mert persze kimaradt az RTFM. Csináltam magamnak jegyzetet az egész sztoriból, csak Ubuntu alapon, majd belinkelem ide, ha egyszer publikálom.

Még egy apróságot megemlítenék a cikkben, hogy az apache nginx-re cserélésével nyert stacket pedig LEMP-ként szokás emlegetni.
11

nginx+PHP-FPM telepites cikk

Granc Róbert · 2012. Feb. 13. (H), 13.19
Meg lehet beszelni... :D

/r.
12

Windows

Bártházi András · 2012. Feb. 13. (H), 13.43
Windowsra van ilyen: http://projects.javatic.net/p/easywemp/ - de ez nem PHP-FPM, mert az leginkább csak Linux alatt megy. Illetve Cygwin alá telepíthető. Mac OS X alá viszont sikeresen belőttem.
14

OK

janoszen · 2012. Feb. 13. (H), 13.52
Miutan en szinte csak azt hasznalok, sztem majd megejtem.
9

Ami a webfejlesztést illeti,

kuka · 2012. Feb. 13. (H), 12.27
Ami a webfejlesztést illeti, a PHP, Perl, Python hármas közül leginkább a Perl az, ami vesztett a népszerűségéből, a másik két nyelv inkább csak növekedett, s olyan nyelvek csatlakoztak hozzájuk, mint a Ruby, vagy akár a JavaScript.
Sajnos én is így vettem észre, viszont a TIOBE Programming Community Index for February 2012 szerint az utóbbi évben az említett nyelvek közül pont a Perl az egyetlen amely gyarapodott:
Position Feb 2012Position Feb 2011Delta in PositionProgramming LanguageRatings Feb 2012Delta Feb 2011Status
65-PHP5.641%-1.33%A
84----Python3.148%-3.89%A
910+Perl2.931%+1.02%A
109-JavaScript2.465%-0.09%A
1211-Ruby1.558%-0.06%A
15

Nem ilyen tavlatban

janoszen · 2012. Feb. 13. (H), 13.53
Ne ilyen tavlatban nezd, hanem mondjuk 5-10 evre.
16

Mondasz te valamit… Így picit

kuka · 2012. Feb. 13. (H), 14.13
Mondasz te valamit… Így picit másabb.
Programming LanguagePosition Feb 2012Position Feb 2007Position Feb 1997Position Feb 1987
PHP64--
Python8727-
Perl965-
JavaScript10925-

(Idemásoltam hátha pár év múlva még szóba kerül és akkor lehet már nem lesz meg.)
(És hogy ne sértsünk jogokat: forrás – TIOBE Index.)
25

C*

janoszen · 2012. Feb. 15. (Sze), 01.28
Azért az durva, hogy a C# és az Objective-C mennyire odavert a mezőnynek. És szépen látszik a 2011-es Python hype is. :D

26

Érdekes :D Mi történt 2004 és

inf · 2012. Feb. 15. (Sze), 05.15
Érdekes :D Mi történt 2004 és 2006 között a java-val? Nagyon megzuhant, a konkurencia meg nagyon megerősödött akkor... :-)
28

-

Trudy · 2012. Feb. 15. (Sze), 10.57
1 szó : Oracle
20

Most ez lehet valami hülye

Karvaly84 · 2012. Feb. 13. (H), 21.27
Most ez lehet valami hülye kérdés lesz, de a NoSQL-nek nincs köze az SSD meghajtókhoz?
21

Nincs

Poetro · 2012. Feb. 13. (H), 22.03
Miért lenne köze? Lehet SQL adatbázist is tárolni SSD-n, és attól az is gyorsabb lesz. Meg lehet NoSQL adatbázist is hagyományos HDD-n tárolni (mazochisták tárolhatják flopi lemezen is mindkettőt).
22

Lyukkártya?

Joó Ádám · 2012. Feb. 15. (Sze), 00.11
Lyukkártya?
27

Nem jó! :)

H.Z. v2 · 2012. Feb. 15. (Sze), 10.43
Rendeltetésszerűen használva ez egy WORM adathordozó, ráadásul - ami nagyobb gond - szekvenciális elérésű! ;))
29

De jó

Pepita · 2012. Feb. 15. (Sze), 13.22
Miért lenne gond a szekvencialitás? Idő mint a tenger! ;)
30

Mert adatbázisról beszélünk. :)

H.Z. v2 · 2012. Feb. 15. (Sze), 13.52
Látszik, hogy nem dolgoztál lyukkártyával... A "jófajta" ruszki olvasók néhány olvasás után elkezdték begyűrni a kártyákat.
Másrészt - bár előfordulhat olyan alkalmazás, ami read only adatbázissal dolgozik - azért lássuk be, 80 oszlopos kártyákkal eljátszani egy-egy update-et... még akkor is macerás, ha van a géphez lyukkártya lyukasztó. :D
(olyat viszont nem láttam... csak lyukszalagost, de az megint más játék ;)) )
31

Hát annyira nem is vagyok "öreg"

Pepita · 2012. Feb. 15. (Sze), 14.27
De volt szerencsém ZX81-hez, Videoton TV Computer-hez, és hasonlók...
És - ha már dicsekszem - van egy C16-osom a szabvány 1541-es floppy-val.

Különben a kártyagyűrés szerintem nem gond, sok embernek munkát adhatott... Az update meg tartson csak 2-3 hétig. "Mindig friss adatokkal dolgozunk!"
32

Na ne

Hidvégi Gábor · 2012. Feb. 15. (Sze), 14.36
Fiatalabbnak hittelek valamiért.
34

Az is vagyok

Pepita · 2012. Feb. 15. (Sze), 14.50
(38) Ezekhez tanulógyerekként volt szerencsém, vmi úttörős szakkörön, vagy minek hívták. De tetszett nagyon. Csak aztán mégis gépész lettem...
35

Akkor félig-meddig kollegák

Hidvégi Gábor · 2012. Feb. 15. (Sze), 14.56
Akkor félig-meddig kollegák vagyunk, a BME Gépészmérnöki karán végeztem Terméktervező szakon.
33

nosztalgia :)

H.Z. v2 · 2012. Feb. 15. (Sze), 14.43
Szerencsére nem, mert rendeltetésszerű használat esetén viszonylag ritkán kellett kártyaolvasóval bajlódni. Ami kártyán jött (pl. forrásprogramok), bement diszkre vagy mágnesszalagra, oszt' jónapot. Ha javítani kellett, akkor többnyire csak a javítás ment be, sokszáz kártya helyett tíz-húsz darab.
Jó játék volt... A kártyalyukasztó gépek klaviatúráját visszasírom azóta is. Meg a CICS-hez használt IBM 3270-es (3278 valójában) terminálokét is... :)
36

Billentyűzet

Poetro · 2012. Feb. 15. (Sze), 15.22
Tudtommal a '80-as években gyártott IBM billentyűzetek (még hagyományos billentyűzet csatlakozóval) még mindig nagyszerűen működnek, és egy-egy jó állapotban levő darab még mindig sokat ér a használt piacon.
37

Ezek nem PC-s billentyűzettel

H.Z. v2 · 2012. Feb. 15. (Sze), 15.37
Ezek nem PC-s billentyűzettel működtek. Mondjuk az IBM terminál esetében talán csak a távolság szépíti meg az emlékeket, de a Soemtron lyukasztó elektromechanikus billentyűzete... azt imádtam. :)
Nyomtad lefelé és a végén magától beugrott a végállásba, majd vissza. :)
23

Hmmm... a megrendelőt és a

Oregon · 2012. Feb. 15. (Sze), 00.12
Hmmm... a megrendelőt és a felhasználót nem hatja meg a technológia.
Felhasználhatóság, biztonság, szépség, működőkepésség.
Ezeken pedig leginkább a minőségi munka iránti vágy javít, ha ez nincs meg valakiben, akkor cseszheti.
24

Megrendelő

janoszen · 2012. Feb. 15. (Sze), 01.27
Ez tipikusan nem az a kérdéskör, ahol megrendelő vs. kivitelező szerepkörökre van leosztva a játék, hanem webalkalmazásoknál, ahol egy szoftver több vason fut, nem egy vason több szoftver. Ott ugyanis már lehet ilyesmivel nagyságrendeket optimalizálni illetve skálázódási problémákra felkészülni.
38

Értem. Engem elkerül az ilyen

Oregon · 2012. Feb. 15. (Sze), 22.37
Értem. Engem elkerül az ilyen probléma, ezért ehhez nem is értek. :)
Nekem még egy dedikált vas teljesítménye is rengeteg.
39

Nem olyan biztos, hogy itt az "alkonyat"

mapdesign18 · 2012. Feb. 25. (Szo), 13.35
Sziasztok,

Az Apache Foundation - hat év után először - új főverziót adott ki névadó webkiszolgáló szoftveréből. Az új Apache 2.4 a szervezet szerint jelentős előrelépést jelent a korábbi kiadásokhoz képest, mind a teljesítmény, mind a rugalmasság terén.

A fejlesztéseknek köszönhetően az új Apache kevesebb erőforrást - memóriát és processzort - igényel azonos terhelés mellett, a kéréseket pedig - részben az új aszinkron I/O-támogatásnak köszönhetően - jobban párhuzamosítva képes kiszolgálni. A készítők szerint a szoftver így már legalább olyan jó teljesítményt tud nyújtani, mint az utóbbi időben a kárára jelentősen előtörő, teljesen eseményvezérelt más kiszolgálók (mint pl. az nginx).

Szintén újdonság, hogy a korábbiaknál jobban lehet a kapcsolati jellemzőket - mint például az időkorlátok és a feldolgozási határértékek - konfigurálni, de a hatékony gyorstárazást is több opcióval segíti az új kiszolgáló. Terheléselosztásos környezetekben az új, dinamikus reverse proxy konfiguráció is jól jöhet majd az üzemeltetőknek.

@url: http://httpd.apache.org/docs/2.4/new_features_2_4.html
@url: http://httpd.apache.org/
@url: http://prog.hu/hirek/2939/Letoltheto+a+vadiuj+Apache+2+4+webkiszolgalo.html

PS: Ugyan még nem teszteltem, de ha van olyan jó teljesítményjavulás mint az nginx esetében, akkor ez jó hír sokak számára.
40

Olvastam

Bártházi András · 2012. Feb. 26. (V), 16.51
Igen, olvastam, még én sem próbáltam ki. Ha valaki tud linket konkrét mérésekről, tegye majd közzé! Nekem az egyik szerverem még Apache-ot használ, de a hír sem ingatott meg abban, hogy átálljak nginx-re (majd ha tudok majd időt szakítani rá).