nginx - apache2

Internet: PHP, CGI, stb.

Hejho!

érdeklödni szeretnék hogy kinek mi a vèlemènye a linkelt cikkröl. Fontos-e, hasznos-e, vagy inkabb felesleges?

www.packtpub.com/article/configuring-apache-and-nginx

köszi
Wolfi

  • 8194 megtekintés

( andrej_ v | 2012. 02. 02., cs – 11:24 )

Ez erősen felhasználás és konkrét konfig/igény függő. Ha ezzel mondjuk harmadával vagy felével tudod csökkenteni az erőforrás (memória/cpu) igényed egy VPS-en akkor rögtön számszerűsíthetően megéri. Ezen kívül persze sok más hasznos előnye is lehet az adott helyzettől függően.

Én lighttpd+apache-al csinálok hasonlót és az időszakos Apache elszállásokat sikerült szinte teljesen visszafogni, amik egy-egy hirtelen megugró látogatásából adódtak.

Levehetsz némi terhelést róla azzal, hogy a static fájlokat arról szolgálod ki. Ez nem lesz sok. Valamint bufferelheted a requestet, hogy kevesebb szálat egyen. De aki be akar dosolni, az keres magának egy olyan részt az oldaladon, ami jó lassú és azt fogja húzni. Na és ezen nem segít a nginx.

Azért írtam végül a fórumba, mert nagyon sok helyen olvastam hogy az nginx önmagában is megállja a helyét az apache2 helyett. Ebből a szempontból viszont "felesleges" két kiszolgálót beiktatni. Másik szempont viszont az, hogy így megvédhetjük a cikkben backend-nek emlegetett kiszolgálót.

jah, de ha az ember olyan környezetben használja (pl nem olyan helyre, ahol ügyfelek töltögetnek/használják), hanem csak egy bizonyos dolog kiszolgálására van tervezve, ott inkább átírja az ember nginx-re a htaccess -t mint hogy kétszer futtassa ugyanazt a feladatot ellátó dolgot.

Ha a felhasználók gyártják a cuccokat a gépedre, akkor szerintem nem kintről kell várnod a támadást, hanem onnan, hogy valamelyik balmadár gyárt egy pár százezer soros táblát a MySQL-ben indexek nélkül és azon futtat jó sok tényezős lekérdezéseket. Az nginx pedig semmi olyat nem tud, amitől sokkal nyugodtabban alhatnál.

Annak már volna értelme, ha minden felhasználónak indítanál egy saját Apacheot lecsupaszítva feltétlenül szükségesre és oda proxyznád a felhasználó domainjeit, mert akkor legalább azon a ponton csak magát tudja bedosolni.

> Annak már volna értelme, ha minden felhasználónak indítanál egy saját Apacheot lecsupaszítva feltétlenül szükségesre és oda proxyznád a felhasználó domainjeit, mert akkor legalább azon a ponton csak magát tudja bedosolni.

A szervert ugyanúgy kinyírja, teljesen mindegy, hogy külön indítasz neki külön Apache-ot vagy akármit.
Nyilván annyiból jobb a helyzet, hogy itt már vannak lehetőségek: valamilyen memória, CPU korlátozás, külön szerveren futtatás, stb.
Még a külön szervernél is meg van az esély arra, hogy a lassú kiszolgálás miatt sok szál beáll a frontenden és emiatt elfogynak, valószínűleg megfelelő konfigurációval ez is elkerülhető.

+
eddigi tapasztalataim szerint a legtöbb támadás nem okoz komoly fennakadást. Esetleg konkrétan abban a percben némi lassulás. A szokásos sakkozás a timeout-okkal és a többi apró kis beállítási trükknek köszömhetően (nameg persze modoknak is) az apache2 lehet hogy kifut a konfigból de 4-5loadnál többet nem ér el, valamint 8GB memória áll rendelkezésre.

Tfh. az egyik usered olyan scripteket szeret írni, amik jó sokáig futnak (és nem CPU-ból fogyasztják el a gépedet). Na erre pl. könnyű olyat írni, ami meghúzza azt a részét a programnak. Következés szépen ki fogsz fogyni az Apache szálakból. Hogy ez ne érintsen minden oldalt, hanem csak azt, ami barkács módon van megírva, alkalmazhatod ezt a technikát.

Ha nem is ilyen iranyban, de gondolkodok tobb apache inditasan, nginx-szel valo routolasan. Az apache oldalat hogy erdemes felkonfigolni ugy, hogy lehetoleg minimalisat tudjon az ugyfel terhelni, de megse kapjon a nginx HTTP 50x-at?
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Az nginx-et érdemes inkább confolni, pl. a request body méretet beállítani, illetve a proxy bufferméreteit kikisérletezni.

Ami az Apacheot illeti, ha felhasználói cuccokról van szó, akkor nem nagyon tudsz mit csinálni vele, mert a PHP lesz a hunyó. Esetleg annyi, hogy valami lightweight virtualizációba bevágni a usereket.

Én egy pár éve nézegettem az itk-t, de a forrásában voltak olyan dolgok, amik nem tetszettek. Ehhez hozzájön az is, hogy rootként fut, amíg usert nem vált.

Ami az egyéb beállításokat illeti, kisérletezés függvénye. 50-nél kevesebb szálra nem érdemes lemenni és 600 fölé sem. A 600 az akkor játszik, ha nagyon sok IO műveletet végez a szerver, amire várni kell (pl. külső API-k hívása) és elég nagy a terhelés rajta.

En nem nezegettem a forrasat, ellenben a legjobb megoldas amit ismerek, amennyiben nincs ugyfelpanasz ra, cserebe nagyobb biztonsagot ad, mintha mpm_prefork lenne, www-data userrel. Ha az ember osszedob egy SELinux-ot, vagy AppArmort, vagy ilyesmit, akkor mar elegseges biztonsagot ad. Nem azt mondom, hogy nem lehetne _sokkal_ biztonsagosabb, csak amikor eleve keves eroforrasa van az embernek, akkor nem biztos, hogy erre akarja szanni.

Az elkepzelesrol inkabb irok PM-et, mert erdekelne a velemenyed, de egyelore nem akarom megszelloztetni az uj szolgaltatast.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( wolfnet | 2012. 02. 13., h – 20:54 )

Sziasztok!

Kicsit tesztelgettem a dolgokat, végre időm is engedte. Sikerült rendben összehangolni az nginx-apache2 kombót a fő postban leírtak alapján. Azt tapasztaltam, hogy ha reprodukálunk egy flood attack-ot, akkor az apache2 megdöglik az nginx békésen vár, majd 502es gateway error-al kidob. Tulajdonképpen bármit küld az nginx az nem keepalive folyamat lesz hanem mezei (prefork worker apache2). Kérdezem, hogy ezt el lehet-e érni valahogy.

@szerk: mert így nem óvja meg az indiánt, csak annak a néhány szerencsésnek aki a cache időn belül van.

Ha ugyanazt 8000000000000x lekérik 1mp-en belül akkor édesmind1, mint teszel előre/hátra/középre. :) Esetleg valamilyen perip maximális kapcsolattal vagy más hasonlóval lehet próbálkozni. Ezzel meg óvatosan kell, mert a Firefox 10-15 kapcsolatot nyit alsóhangon és egy netkávézó/iroda könnyen elérhet 50-100 kapcsolatot is egy IP-ről. Az ellen tudsz védekezni, hogy a képeket/css/js és más ilyesmit nem hagysz eljutni az Apache-ig. A hatalmas memóigényű Apache processzek elég hamar kitömnek 4-8GB memót is ha beindul egy site, de gondolom ez nem újdonság. :)

igen-igen pont erre találták fel az indiánnál a Keepalive request-et. Ha ez a nyomorult nginx valóban azt csinálná amit a configban megadtam minden rendben lenne.

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Ezeknek kellene az apache2-höz a tényleges ip címet eljuttatni, ennek ellenére maradunk localhostnál, aminek az az eredménye ahogy írtad is, minden egyes beérkező kérés külön szálat kap, ami életveszélyes, és ebből adódóan felesleges elérakni akármilyen jól cachelő programot.

FYI: ez nem az nginx hibaja. Te az nginx szintjen megadod az apache fele headerekben, hogy mi volt az eredeti kapcsolodasi pont. Hogy az apache nem ezt veszi alapul, hanem a client socketbol szamitott tavoli cimet (ami jelen esetben az nginx cime, ami localhost), azert nem teheted az nginx-et felelosse. Nincs mod arra, hogy magat a socketet atproxyzd ugyanis, mindig ket socketed lesz nyitva.

Megoldas: mas modon megoldani a problemat, nem keepalive-val. Akar pl. ugy hogy felemeled az egekbe az apache oldalan az egy szal altal kiszolgalhato requesteket, de nem a per-ip -s verziot (eleg koran van meg, hogy ne jusson eszembe a beallitas neve).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

igen igen igen, először szerkesztettem a postomat majd rájöttem hogy butaság ezért töröltem. Igazából az apache2 nem "értelmezi" valóban ahogy írjátok. A gyakorlati életben azonban nincs vele komoly gond, mint az itthon felépített tesztkörnyezetben. Az biztos hogy a mindennapos böngészés felgyorsult, az apache2 majdnem egésznap fix folyamat mennyiséggel dolgozik, ami azért haladás.

Nem ez itt a valódi probléma véletlen?

Nginx is a HTTP/1.0 proxy and as such does not support keep-alive requests to the backend. Threfore, backend connections are created and destroyed on every request. HTTP/1.1 proxying is currently available in the development version so if needed you can use that. Nginx is fully HTTP/1.1 to the browser and as such it handles keep-alive to the browser.

http://wiki.nginx.org/HttpProxyModule

Itt szerintem nagyjából jól le van írva minden ebben a témában, ugyanúgy igaz valsz nginx-re is:
http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip…

Gondolom, ha nem szolgálsz ki egy csomó már eleve tömörített tartalmat, amivel csak szenved a szerver és a browser feleslegesen, akkor érdemes kipróbálni és megnézni, hogy mit hoz a dolog.

Amúgy meg nem hiszem, hogy ez webszervertől függene, hogy érdemes-e gzip-et használni vagy sem.

Igen azt tudtam eddig is hogy az az előnye hogy csökkenti az adatforgalmat viszont növeli a cpu terhelést.

@szerk: még egy észrevétel. Amikor le szeretnék tölteni egy fájlt, nagyon küzd, nagyon küzd 1-2-3kB/s, majd megindul. Nincs is gond ezzel egészen addig, amíg például nem egy dvd iso-t szeretnél megosztani. Tehát nagyon lassú a letöltés. Plussz ha menet közben megszakítod a letöltést, akkor az apache2 továbbra is küldeni szeretné az adatot és zombie folyamatok keletkeznek, ami rossz.