Apache vagy Nginx: gyakorlati szempontok

VPS csomagjaink

Tartalomjegyzék

1. Bevezetés
2. Általános áttekintés
3. A kapcsolatvezérlő felépítése
4. Statikus vagy dinamikus tartalom
5. Osztott vagy központosított konfiguráció
6. Fájl vagy URI-alapú értelmezés
7. Modulok
8. Támogatás, összeférhetőség, ökoszisztéma és dokumentálás
9. Az Apache és Nginx együttes használata
10. Összegzés

Bevezetés

Az Apache és Nginx a két leggyakrabban  használt nyílt forráskódú webszerver a világon. Együttesen az interneten bonyolított forgalom 50%-át teszik ki. Mindkét megoldás lehetőséget ad különböző munkaterhelésekre és másik szoftverekkel való dolgozásra, így egyfajta web stacket alkotva.

Habár az Apache és Nginx sok közös tulajdonsággal rendelkeznek, nem szabad azt gondolnunk, hogy a kettő felcserélhető. Mindkettő különböző területeken emelkedik ki, és fontos megértenünk, hogy akadhatnak olyan szituációk, ahol hasznos átgondolnunk, hogy melyik webszervert válasszuk.

Ezen cikk a két webszerver különböző felhasználási területeit igyekszik lefedni.

Általános áttekintés

Mielőtt beleássuk magunkat az Apache és Nginx közötti különbségekbe, nézzük meg a két projekt előzményeit és általános tulajdonságait.

Apache

Az Apache HTTP szerverét Robert McCool hozta létre 1995-ben és fejlesztett tovább az Apache Software Foundation (Apache Szoftver Alapítvány) neve alatt 1999-től kezdve. Mivel a HTTP webszerver az alapítvány eredeti projektje, és azóta is messze a legsikeresebb szoftvere, ezért általában csak „Apache” néven szokás emlegetni. Az Apache webszerver 1996 óta a legsikeresebb szerver az interneten. A sikerességének köszönhetően nagy bevétele származik a dokumentációkból és a más szoftverek projektjeinek integrált támogatásából.

Rugalmasságának, erejének és széleskörű támogatottságának köszönhetően gyakran választják a rendszergazdák. Egy dinamikusan terhelhető modulrendszerrel lehet kiterjeszteni, ami képes megannyi nyelv feldolgozására is anélkül, hogy ehhez egy különálló szoftvert kellene igénybe vennie.

Nginx

2002-ben Igor Sysoev kezdett el dolgozni az Nginx-en, problémát keresve a C10K-es problémára (10.000 egyidejű kapcsolat kezelése), ami akkoriban kihívást jelentett a webszerverek számára, márpedig ez alapfeltétele volt a modern világhálónak. Az első nyilvános verziót 2004-ben adták ki, amely egy aszinkronizált, esemény-vezérelt felépítésen alapult.

A kicsi erőforrás kihasználása és minimális hardware-en való hibátlan működése miatt az Nginx népszerűsége kiadása óta is folyamatosan nő. Az Nginx kiválóan kezeli a statikus tartalmakat, és úgy hozták létre, hogy a dinamikus igényeket egy másik szoftverhez irányítja, amely annak kezelésére jóval alkalmasabb.

Az Nginx-et gyakran használják a rendszergazdák, ugyanis rendkívül erőforrás hatékony és terhelés esetén is megfelelő reagálóképességgel rendelkezik. A támogatók örömmel fogadják, hogy az Nginx igen nagy figyelmet szán a belső webszerverekre és a proxy jellemzőire.

A kapcsolatvezérlő felépítése

Egy nagy különbség az Apache és az Nginx között az, ahogyan a kapcsolatokat és a forgalmat kezelik. Talán az egyik legjelentősebb különbség az, ahogyan a forgalomra reagálnak különböző körülmények között.

Apache

Az Apache rendelkezésünkre bocsát egy párhuzamos feldolgozású modult (MPM=Multi Processing Modules), ami meghatározza, hogy hogyan kezelik az ügyfelek kéréseit.

Alapjaiban véve, ez teszi lehetővé a rendszergazdák számára, hogy a kapcsolatvezérlő felépítését egyszerűen cseréljék le. Ezek a következőek:
mpm_prefork: Ez a feldolgozó modul megtöbbszörözi a folyamatokat egy egyszerű végrehajtási szállal annak érdekében, hogy a felkérést kezelni tudják.

Ameddig a kérések száma kisebb a folyamatok számánál, addig ez az MPM nagyon gyors. Azonban a teljesítmény gyorsan csökken, ha a kérések száma meghaladja a folyamatok számát, így sok esetben ez nem túl jó választás. Mivel a jó teljesítőképesség nagyban függ a RAM használattól, így ezt az MPM-et nehéz mérni. Jó választás lehet akkor, hogyha másik egyéb összetevővel használjuk együtt, amik nincsenek vele egy végrehajtási szálon. Például a PHP nem szálbiztos, így ez az MPM az egyetlen ajánlatos és biztonságos módja a mod_php-val való dolgozásnak (az Apache modul ezen fájlok feldolgozására).
mpm_worker: Ez a modul olyan módon többszörözi meg a folyamatokat, hogy azok külön-külön is képesek legyenek több végrehajtási szálat irányítani. Minden egyes ilyen végrehajtási szál egy egyedülálló kapcsolatot képes kezelni. A végrehajtási szálak jóval hatékonyabbak, mint a folyamatok, ami azt jelenti, hogy ez az MPM jobban teljesít, mint a prefork MPM. Mivel több végrehajtási szál van, mint amennyi folyamat, ez azt jelenti, hogy az új kapcsolatok rögtön egy új végrehajtási szálhoz kerülnek, és nem kell egy adott folyamat megüresedésére várnunk.
mpm_event: Ez a modul sok esetben hasonló a worker modulhoz, de arra optimalizálták, hogy kezelje az életben-tartandó kapcsolatokat. A worker MPM használata közben a kapcsolat fel fog tartani egy végrehajtási szálat a kapcsolat teljes időtartama alatt attól függetlenül, hogy az aktív-e. Az event MPM az életben-tartandó kapcsolatokat kezeli és továbbítja az aktív kéréseket más végrehajtási szálaknak. Ez lehetővé teszi, hogy a modul ne rekedjen meg az életben-tartandó kérések miatt, így gyorsabb végrehajtást eredményez. Ez a modul az Apache 2.4 kiadásával együtt lett stabilnak nyilvánítva.
Ahogyan láthatjuk, az Apache rugalmas felépítést és kéréskezelő algoritmust kínál a különböző kapcsolatokhoz. A választások általában a szerver fejlődésétől és növekedő igényeitől függnek, ilyen lehet például az egyidejűségre való igény növekedése.

Nginx

Az Nginx az Apache után jelent meg, nagyobb figyelmet szentelve az egyidejűséggel kapcsolatos problémákra. A rendelkezésünkre álló tudás növekedésével az Nginx úgy lett kialakítva, hogy aszinkronizált, blokkolásmentes, eseményvezérelt kapcsolatkezelő algoritmussal dolgozzon.

Az Nginx megtöbbszörözi a munkafolyamatokat, amelyek mindegyike képes kapcsolatok ezreit kezelni. A munkafolyamatokat úgy végzik el, hogy egy gyors ciklusú mechanizmust alkalmaznak, ami folyamatosan keresi és feldolgozza az eseményeket. A valós munka kapcsolatokról való leválasztásával lehetővé teszi minden dolgozó számára, hogy csak akkor foglalkozzon egy kapcsolattal, amikor egy új esemény elindult.

Minden dolgozó által kezelt kapcsolat egy eseményciklusba (event loop) kerül, ahol más kapcsolatokkal együtt tárolják őket. A ciklusban az eseményeket aszinkronizálva dolgozzák fel, így lehetővé téve a blokkolásmentes munkavégzést. Amikor a kapcsolat véget ér, akkor az kikerül a ciklusból.

Ez a fajta kapcsolatfeldolgozás lehetővé teszi az Nginx számára, hogy limitált erőforrásokkal is rendkívül hatékonyan működjön. Mivel a szerver egyedülálló végrehajtási szálú és a folyamatok nincsenek többszörösítve minden egyes új kapcsolat kezelése esetén, a memória és a CPU használat viszonylag konzisztens marad, még durva túlterhelés esetén is.

Statikus vagy dinamikus tartalom

A valós, gyakorlati esetekben az Apache és Nginx összehasonlításakor legtöbbször a statikus és dinamikus tartalmak kezelését figyelik meg.

Apache

Az Apache szerverek a szabályos fájlalapú módszerekkel kezelik a statikus tartalmat. Ezen tevékenységek főként a feljebb említett MPM módszerek. Az Apache dinamikus tartalmat is képes feldolgozni úgy, hogy beilleszt egy a szóban forgó nyelvvel megegyező processzort minden dolgozó esetében. Ez lehetővé teszi, hogy dinamikus tartalmat hajtson végre a webszerverről anélkül, hogy külső komponensekre kellene támaszkodnia. Ezeket a dinamikus processzorokat engedélyezhetjük a dinamikusan terhelhető modulok által. Az Apache belső dinamikus tartalom kezelő képessége azt jelenti, hogy a dinamikus feldolgozás egyszerűbbé válik. A kommunikációt nem kell egy külön hozzáadott szoftverrel irányítani, és a modulokat könnyen kicserélhetjük, ha a tartalmi követelmények megváltoznak.

Nginx

Az Nginx alapvetően nem alkalmas dinamikus tartalom elérésére. Ahhoz, hogy PHP és egyéb dinamikus tartalmú kérelmeket kezeljen, az Nginxnek egy külső processzornak kell elküldenie a tartalmat, majd megvárni, amíg az visszaérkezik. Így az eredmények már átadhatóak az ügyfél számára. A rendszergazdák számára ez azt jelenti, hogy a kommunikációt konfigurálniuk kell az Nignx és a processzor között egy olyan protokollal, amely kompatibilis az Nginx-szel (http, fastCGI, SCGI, uWSGI, memcache). Ez egy kicsit bonyolíthatja a dolgokat, különösen akkor, ha előre próbáljuk meg meghatározni az engedélyezni kívánt kapcsolatok számát, mivel plusz egy kapcsolat a processzor hívásához lesz használva. Ettől eltekintve ennek a módszernek is megvannak az előnyei. Mivel a dinamikus értelmező nincs beágyazva a munkafolyamatba, ezért ez a többlet csak a dinamikus tartalmaknál van jelen. A statikus tartalmakat közvetlen módon lehet kezelni, és az értelmező csak akkor lesz használatban, amikor arra szükség van. Az Apache is működhet ezen elv alapján, de ha ezt a módszert alkalmazzuk, akkor az előző részben bemutatott előnyök nem lépnének érvénybe.

Osztott vagy központosított konfiguráció

A rendszergazdák számára az egyik legszembetűnőbb különbség a két szoftver között az, hogy engedélyezi-e könyvtárszintű konfigurálást a tartalmak könyvtárában vagy sem.

Apache

Az Apache kínál számunkra egy olyan opciót, ami direktívák vizsgálatával és értelmezésével teszi lehetővé a könyvtárszintű konfigurációt a tartalmak könyvtárának rejtett fájljaiban. Ezeket a fájlokat htaccess fájloknak nevezzük.

Mivel ezek a fájlok a tartalmi könyvtárban vannak tárolva, amikor egy kérést kezel, az Apache egy htaccess fájlt keresve leellenőriz minden komponenst az adott elérési úton, és alkalmazza az abban talált direktívákat. Ez hatékonyan engedélyezi a webszerver osztott konfigurációját, amit gyakran URL átírásokra, elérések korlátozására, engedélyezésére és hitelesítésére használnak, vagy akár gyorsítótárak szabályrendszeréhez is.

Habár a fenti példákat mind meg lehet oldani a fő Apache konfigurációs fájl segítségével, a htaccess fájloknak is van néhány fontos előnyük. Először is, mivel ezek minden egyes alkalommal interpretálva vannak, így rögtön, a szerver újratöltése nélkül használják őket. Másodszor pedig, lehetővé teszi, hogy a hozzáféréssel nem rendelkező felhasználók is irányíthassák a saját webtartalmuk egy részét anélkül, hogy számukra az egész konfigurációs fájlhoz hozzáférést biztosítanánk.

Ez egy egyszerű módszert nyújt néhány webszoftverhez, mint például a tartalomkezelő rendszerekhez, ezáltal a központi konfigurációs fájlhoz való hozzáférés nyújtása nélkül szabhatják testre a környezetet.

A megosztott hoszting szolgáltatást nyújtók is ezt használják azért, hogy a fő beállításokat kézben tarthassák, miközben a megfelelő könyvtárakhoz hozzáférést biztosítanak az adott felhasználók számára.

Nginx

Az Nginx nem értelmezi a htaccess fájlokat, illetve nem biztosít semmiféle mechanizmust a könyvtárszintű konfigurációkra a fő konfigurációs fájlon keresztül. Lehet, hogy kevésbé rugalmas, mint az Apache, de az Nginx-nek is megvannak a maga előnyei.
A legfontosabb javítás a htaccess rendszer könyvtárszintű beállításához képest a megnövekedett teljesítmény. Egy tipikus Apache beállítás engedélyezi a htaccess-t bármelyik könyvtárban, de a szerver átnézi a fájlokat minden egyes szülőkönyvtárban a megfelelő fájlt keresve. Amennyiben egynél több htaccess fájlt talál, úgy minden ilyen fájlt el kell olvasnunk és értelmeznünk kell.

Azzal, hogy nem tesszük lehetővé a könyvtárak felülbírálását, az Nginx gyorsabban ki tudja szolgálni a kéréseket egy egyszerű könyvtárkereséssel és fájlolvasással (amennyiben az adott fájl megtalálható a szabályos könyvtárstruktúrában).

A másik előny a biztonsághoz kötődik. Az osztott könyvtárszintű konfiguráció eléréssel megosztjuk a biztonsággal kapcsolatos felelősséget a felhasználók között, viszont ezen felhasználók között akadhat olyan is, aki ezt nem képes megfelelően kezelni.

Azzal, hogy megbizonyosodunk felőle, hogy a webszerver irányítására csak a rendszergazda alkalmas, sok biztonsági félrelépést spórolhatunk meg (például olyan hibákat, amelyet nem hozzáértő személyek okozhatnak).
Tartsuk észben, hogy a htaccess interpretációt ki is kapcsolhatjuk az Apache-ban, amennyiben aggodalommal töltenek el minket a fent felsoroltak.

Fájl vagy URI-alapú értelmezés

Egy másik különbség, amiben a két szerver eltér, az a kérések értelmezése és a forrás feltérképezése a rendszeren belül.

Apache

Az Apache lehetővé teszi, hogy egy adott kérést fizikai forrásként értelmezzen a fájlrendszerben vagy URI helyként, amely néhány esetben egy elvontabb kiértékelést igényelhet. Általában a régebbi Apache a <Directory> vagy <Files> blokkokat használja, míg elvontabb források esetében a <Location> blokkot alkalmazza.

Mivel az Apache a nulláról lett felépítve, így az alapértelmezett beállítás a kéréseket fájlrendszer forrásként értelmezi. A gyökérdokumentumhoz hozzáírja a kérés hosztot és portszámot követő részét, így igyekszik megtalálni az adott fájlt. Lényegében a fájlrendszer hierarchiája egy dokumentumfaként látszik a weben.

Az Apache felkínál néhány alternatívát azokra az esetekre, amikor a kérésre nincs találat a fájlrendszerben. Például egy aliasz direktívát használhatunk arra, hogy feltérképezzünk egy alternatív helyszínt. A <Location> blokk egy jó módszer az URI-vel való dolgozásra a fájlrendszer alkalmazása helyett.

Létezik néhány általános kifejezésváltozat, amiket abban az esetben használhatunk, ha egy rugalmasabb beállítást szeretnénk fájlrendszerünkben eszközölni. Habár az Apache képes a fájlrendszerben és webes felületen is működni, elég erős fájlrendszeres módszereken alapul. Ezt láthatjuk a dizájn megoldásoknál is, például a htaccess fájlok esetében a könyvtárszintű beállításoknál. Az Apache figyelmeztet minket arra, hogy ne használjunk URI-alapú blokkokat hozzáférés korlátozására abban az esetben, ha a kérés a fájlrendszert tükrözi.

Nginx

Az Nginx webszerverként és proxy szerverként is egyaránt képes funkcionálni. A két szerephez szükséges felépítés miatt elsődlegesen URI-vel működik, és amennyiben szükséges, úgy azt fájlrendszerbe átkódolja. Az Nginx nem nyújt lehetőséget egy specifikus beállítási mechanizmusra a fájlrendszer könyvtárában, hanem szintaktikusan elemzi magát az URI-t. Például az Nginx elsődleges beállítási blokkjai szerver és helyszíni blokkok. A szerverblokk értelmezi a kért hosztot, a helyszíni blokkok pedig az URI hoszt és port után következő részeinek összepárosításáért felelnek. Ezen a ponton a kérés URI-ként van értelmezve, nem pedig locationként a fájlrendszerben.

Statikus fájlok esetében végül minden kérés egy helyszínhez lesz leképezve a fájlrendszerben. Először az Nginx kiválasztja a szervert és a helyszíni blokkot, ami kezeli a kérést, majd kombinálja a gyökérdokumentumot az URI-vel, megváltoztatva minden szükséges dolgot a beállításoknak megfelelően.

Hasonlónak tűnhet, de a kérések URI-ként való szintaktikai elemzésével (fájlrendszeres elhelyezkedés helyett) az Nginx könnyebben funkcionál web, mail és proxy szervereken is. Az Nginx konfigurálása mindössze annyiból áll, hogy beállítjuk, hogy a különböző kérési mintákra hogyan reagáljon. Az Nginx nem ellenőrzi a fájlrendszert addig, ameddig nem áll készen a kérés kiszolgálására, ami megmagyarázza, hogy miért nem használ htaccess fájlokat.

Modulok

Az Nginx és az Apache is bővíthető modulrendszereken keresztül, de ezek a két szervernél jelentősen eltérnek.

Apache

Az Apache modulrendszere lehetővé teszi számunkra, hogy dinamikusan töltsünk fel vagy vegyünk le modulokat attól függően, hogy milyen igényeink vannak egy szerver futtatásával kapcsolatban. Az Apache magja mindig jelen van, de a modulokat ki- és bekapcsolhatjuk, hozzáadva vagy elvéve a funkciókat a fő szervertől. Az Apache feladatok széles köréhez használja a funkcióit. A platform érettségének köszönhetően nagy kiterjedésű könyvtárral és modulokkal rendelkezik. Ezeket felhasználhatjuk arra, hogy a szerver néhány magfunkcióját megváltoztassuk, mint például a mod_php-t, ami beágyazza a PHP értelmezést minden folyamatba. A modulok nincsenek limitálva a dinamikus tartalmak feldolgozását illetően. Más funkciók mellett arra is használhatjuk őket, hogy URL-eket írjunk át, ügyfeleket hitelesítsünk, szervert erősítsük meg, naplózáshoz, gyorsítótárakhoz, tömörítéshez, proxyzás, gyakoriság-korlátozáshoz és titkosításhoz. A dinamikus modulok jelentős mértékben kiterjeszthetik a magfunkciókat anélkül, hogy sok munkát kellene belefektetnünk.

Nginx

Az Nginx is modulrendszert használ, de ez eléggé eltér az Apache által használt rendszertől. Az Nginx-nél a modulok nem dinamikusan tölthetőek, így ezeket ki kell választanunk és be kell szerkesztenünk a szoftver magjába.

Emiatt sok felhasználó számára sokkal kevésbé tűnik rugalmasnak az Nginx. Ez különösen igaz azokra a felhasználókra, akik nem képesek fenntartani egy saját szoftververziót, csak a disztribútor alapértelmezett csomagját tudják kezelni.

Miközben a disztribútorok csomagjai a leggyakrabban használt modulokat tartalmazzák, ha szükségünk van egy nem standard modulra, akkor forrásból kell felépítenünk a szervert saját magunknak. Az Nginx modulok ettől függetlenül nagyon hasznosak, és lehetővé teszik számunkra, hogy meghatározzuk, hogy melyek azok a funkciók, amelyeket használni szeretnénk. Néhány felhasználó lehet, hogy biztonságosabbnak tartja ezt a módszert, mivel nem lehet tetszőleges komponenseket ráaggatni a szerverre.

Sok Nginx modul lehetővé teszi ugyanazt, mint az Apache modulok is. Például az Nginx modulok nyújthatnak számunkra proxy támogatást, tömörítést, gyakoriság-korlátozást, naplózást, újraírást, helymeghatározást, hitelesítést, titkosítást, streaminget, és e-mailhez kapcsolódó funkciókat.

Támogatás, összeférhetőség, ökoszisztéma és dokumentálás

A legfontosabb, amit át kell gondolnunk, az maga a rendszer felállításának folyamata közben felmerülő kérdésekhez elérhető segítség és más szoftverek támogatásának kérdése.

Apache

Az Apache igen régóta tartó népszerűségének köszönhetően a szerver támogatása nagyjából minden gépen jelen van. A felhasználók számára egy kiterjesztett könyvtár áll rendelkezésre első és harmadik személyek által írt dokumentumokkal, a magszerverrel és feladatalapú szituációkkal kapcsolatos témákban, mint például az Apache másik szoftverekhez való kötése.

A dokumentációval együtt más eszközök és webprojektek nyújtanak segítséget ahhoz, hogy saját szoftverüket hogyan töltsük be Apache környezetben. Ezeket tartalmazhatják maguk a projektek, vagy a disztribútori csapat által fenntartott csomagok is.

Általánosságban az Apache szélesebb körben elérhető a harmadik felek által nyújtott projektek tekintetében, pusztán a piaci részesedése miatt, illetve azért, mert régebb óta jelen van. A rendszergazdák nagy része általában Apache tapasztalattal rendelkezik, nem csak a gyakori előfordulása miatt, de azért is, mert sok ember kezdetben egy megosztott hoszting helyzettel kerül szembe, ami majdnem teljesen az Apache-on alapul a htaccess megosztott vezérlő kapacitása miatt.

Nginx

Az Nginx növekvő támogatásnak örvend, ahogy a teljesítményének köszönhetően egyre több felhasználó tér át rá, de még mindig fejlődnie kell néhány kulcsfontosságú területen.

Régebben nehéz volt egy érhető angol nyelvű dokumentációt találni az Nginx-ről, mivel az elsődleges fejlesztések és dokumentációk orosz nyelven zajlottak. Ahogy növekedett a projekt befolyása, a dokumentumokat úgy töltötték fel, és jelenleg számos adminisztratív forrás található az Nginx oldalán, és harmadik személyek által készített tartalmak is fellelhetőek.

A harmadik személyek által készített alkalmazásokat illetően, mivel a támogatás és dokumentálás egyre elérhetőbb, így a disztribúciókért felelős személyek néhány esetben lehetőséget adnak rá, hogy auto-konfiguráljunk Apache vagy Nginx szerverre. Támogatás nélkül is, az Nginx konfigurálása egy alternatív szoftverhez közvetlen módon működik addig, ameddig a projekt dokumentálja a követelményeket (pl.engedélyek).

Az Apache és Nginx együttes használata

Miután végigvettük az Apache és Nginx előnyeit és hátrányait is, valószínűleg van egy átfogó képünk arról, hogy saját szerverünk számára melyik lenne megfelelőbb. Sok felhasználó úgy gondolja, hogy még jobban növelhetik a szervereik erejét azzal, hogy együtt használják őket.

A jól bevett beállítás ehhez a társuláshoz az, hogy az Nginx-et egy fordított proxyként az Apache elé helyezzük. Ez lehetővé teszi az Nginx számára, hogy kezelje az ügyfelek összes kérését. Ez kihasználja az Nginx által nyújtott gyors feldolgozási sebességet és a képességet, hogy egyidejűleg bármekkora számú kapcsolatot kezeljen.

Statikus tartalmak esetében, amiben az Nginx kiváló, a fájlokat gyorsan és közvetlenül az ügyfélnek továbbítja.

A dinamikus tartalmak esetében, például PHP fájloknál, az Nginx átirányítja a kérést az Apache-nak, ami ezután fel tudja dolgozni az eredményeket és vissza tud térni a megjelenített oldalra. Így az Nginx tovább tudja küldeni a tartalmat az ügyfélnek.

Ez a beállítás jól működik sokaknak, mert lehetővé teszi az Nginx számára, hogy egyfajta szétválasztóként működjön (sorting machine). Amelyik kéréseket kezelni tudja, azokat kezeli, amit pedig nem képes, azokat továbbítja. Azzal, hogy lecsökkentjük az Apache által kezelendő kérések számát, redukálhatjuk azon blokkolások számát, amelyek az Apache működése közben, vagy a foglalt végrehajtási szál közben kialakulhatnak.

Ez a konfiguráció lehetővé teszi azt is, hogy plusz, szükség szerint a háttérben működő szervereket adjunk hozzá a rendszerhez. Az Nginx-et beállíthatjuk úgy is, hogy átadjon egy szerverkészletet, így növelve annak rugalmasságát és teljesítményét.

Összegzés

Ahogy az a cikkből is kiderült, az Apache és az Nginx is erős, rugalmas és rendkívül sok lehetőséget nyújt a felhasználók számára. A különféle követelmények és általunk várt mintázatok tesztelésével kiértékelhetjük, hogy számunkra melyik a megfelelőbb szerver.

Vannak olyan különbségek a projektek között, amelyeknek viszonylag nagy hatása lehet a nyers teljesítményre, képességekre és a felmerülő probléma megoldásához szükséges végrehajtási időre.

Ezek azonban egy olyan kompromisszum eredményei, amelyet nem szabad figyelmen kívül hagynunk. Tulajdonképpen nincs egy olyan webszerver, ami minden esetben megfelelő lenne, így azt a megoldást kell választanunk, ami a mi esetünkben a legtesthezállóbb.

Az összehasonlítás forrása a DigitalOcean cikke ugyanebben a témában.