HOVD 2014 - Kedvenc http szerver

HUP

apache
58% (387 szavazat)
boa
0% (0 szavazat)
cherokee
0% (2 szavazat)
hiawatha
0% (2 szavazat)
java servlet container-ek (pl.: tomcat, jetty, ...)
6% (39 szavazat)
lighttpd
8% (51 szavazat)
litespeed
0% (1 szavazat)
microsoft iis
2% (14 szavazat)
nginx
25% (169 szavazat)
thttpd
1% (6 szavazat)
Összes szavazat: 671

( hubidubi | 2014. 12. 15., h – 08:33 )

Így utólag a java servlet containerek megértek volna egy külön szavazást. Ezeket egy kalap alá venni kb olyan, mintha az apache és az nginx került volna egy kategóriába.

( zsolt.k | 2014. 12. 15., h – 22:21 )

Az apache-októl kérdezném (tényleg érdekel): miért? :)

Nem lehet arra ráérezni sztem, a location működése önmagában is elég gondolkozós, ha azt megfejeled az if-fel akkor kampec. Jó kis felvételi tesztet lehetne írni belőle, ehhez képest az algoritmizálás kutyafasza. :)

A lighty és különösen a varnish csinálja ezt jól szerintem, az nginx-ben el van cseszve az egész by design. Ettől persze az nginx ütős és használom, de ez a része akkor is elcseszett sztem.

Ha nem C10k terhelés mellett kell, vagy van sok memóriád vagy havi egy (?) gyors restart belefér, akkor javaslom még a lighty-t nézd meg! ;-)

Nginx-re szavaztam, de az apache nevű szerről lejövést én is a lighty-val kezdtem, jobban is tetszik máig a konfigurációs szintaxisa, és van egy bájos szépsége, de itt-ott apró lépésekkel az nginx mögött van.
Egy ilyen lépés, hogy sokezer párhuzamos kapcsolatnál képes folyni belőle a memória. Bár, lehet, hogy ezt már a nagyon újaknál megoldották. Sőt, ezt is csak fórumtalálatokból meg vs/compare oldalakról tudom, még sose sikerült ilyen problémába ütközzek lightyval. Ami lighty-s szervereim vannak, máig mind teszik a dolgukat jól.

Én általában mindenből megpróbálok sajátot készíteni, bár sokszor opensource alapon tovább indulva, azok azt tudják amit én akarok. Általában egyébként céges környezetben meg nem én döntöm el, hogy mi van a szervereken azok közül általában az apache szokott a legjobb lenni ;)

Leginkább azért használ(hat)ja még valaki, mert sokat tud és/vagy mert ezt ismeri.

lighttpd-nél pl. belefutottam olyanba, hogy kellett volna WebDAV és mivel ilyet nem tud(ott?) a lighty, mindenhol az volt a "megoldás", hogy húzz fell egy Apache-t a :81-re és proxyzz a lightyvel...

Ettől függetlenül a hátam közepére se kívánom a konfig fájljait. (Sőt, magát az Apachet, ha minden jól megy, tavasszal megszabadulok az utolsótól is itt, aztán maximum a Wines fejlesztői gépeken marad.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

- Mert nincs nginx modul WildFly-hoz (mod_cluster).
- Nem találtam olyan mérést komplex szolgáltatások esetén, amelyik meggyőző fölényt mutatna, eléggé vegyesek eredmények, attól függően, hogy a mérést készítő mit szeretett volna kihozni eredménynek és milyen hardveren futtattak. Csodák nincsenek...
- Az Apache még mindig svájcibicska az nginx-hez képest.
- Az Apache működésmódja és beállításai nem változtak évek óta, nem kell azon aggódni, hogy frissítés után menni fog-e minden ugyanúgy.
- Koherens és letisztult a konfiguráció, nincs az az érzésem, hogy sok különböző ember fejleszti és másképp neveznek dolgokat, esetleg átneveznek dolgokat.

Bónusz: kevesebb szívás van az Apache-al... amikor nginx esetén a WebSocket proxy esetén napokon át azt kerestem, hogy mi és vajon miért bontja a kapcsolatot, ha nincs rajta forgalom, akkor azért eltartott egy ideig, amíg kiderült, hogy kell egy külön "proxy_read_timeout 999999999;" a konfigurációba, különben 30 másodperc után bontja a ws kapcsolatot is... :/

"Koherens és letisztult a konfiguráció"

Apachenal? Megis hol? Fele valami XML kezdemény, fele meg nem... Arról nem beszelve, hogy szerintem ciki, hogy 2014-ben meg mindig ott tartunk, hogy egy vhost módosításához az egesz configot ujra kell húzni. (Ebben mondjuk a lighty es az nginx se jobb).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™"

"Apachenal? Megis hol? Fele valami XML kezdemény, fele meg nem..."

Nem a formátuma, hanem az elnevezések, a konvenciók, a működésmód, a logika...

"Arról nem beszelve, hogy szerintem ciki, hogy 2014-ben meg mindig ott tartunk, hogy egy vhost módosításához az egesz configot ujra kell húzni."

Egyrészt egy 'reload' vagy egy 'graceful' nem annyira fájdalmas még aktív WS kapcsolatokkal se, másrészt éles környezetben az ember nem turkál, tesztkörnyezetben meg elfér egy pár másodperces restart is.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Hja logika... Hányszor szívtam amiatt, hogy megadtam a globális(nak gondolt) documentrootot, aztán mégis szart rá.

"nem annyira fájdalmas"

Hja, csak másik oldalon a lenézett IIS-nél meg tudták oldani valahogy azt, hogy ne kelljen már az egész IIS-t restartolni, mert mondjuk ki/be dobálok egy random oldalt, webappot, fcgi handlert, stb.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"Hja logika... Hányszor szívtam amiatt, hogy megadtam a globális(nak gondolt) documentrootot, aztán mégis szart rá."

...és mi volt a baj? Mert én nem emlékszem, hogy ilyesmi miatt lett volna bármi problémám, de emlékezhetek rosszul.

"Hja, csak másik oldalon a lenézett IIS-nél meg tudták oldani valahogy azt, hogy ne kelljen már az egész IIS-t restartolni, mert mondjuk ki/be dobálok egy random oldalt, webappot, fcgi handlert, stb."

Emlékem szerint IIS-nél a mod_rewrite megoldás az igazi szopás...

...mindegyik megoldásnak vannak előnyei-hátrányai, problémái és kényelmes megoldásai.

"...és mi volt a baj? "

Mit tudom én már. Azt hiszem, talán külön vhostokat kellett felvenni rá. Máshol (pl. lighty) ez sokkal egyértelműbben működik. Maga a konfig is olvashatóbb szerintem.

"Emlékem szerint IIS-nél a mod_rewrite megoldás az igazi szopás..."

Nem ez volt a kérdés.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

- Mert nincs nginx modul WildFly-hoz (mod_cluster).

Ezt nem vitatom.

- Nem találtam olyan mérést komplex szolgáltatások esetén, amelyik meggyőző fölényt mutatna, eléggé vegyesek eredmények, attól függően, hogy a mérést készítő mit szeretett volna kihozni eredménynek és milyen hardveren futtattak. Csodák nincsenek...

Az nginx nagyságrendekkel gyorsabb. Végeztünk elég sok mérést már ezzel kapcsolatban, tele van a net is ilyen mérésekkel, de 2014-ben ez már tény, nem kérdés.

- Az Apache még mindig svájcibicska az nginx-hez képest.

Inkább fordítva.

- Az Apache működésmódja és beállításai nem változtak évek óta, nem kell azon aggódni, hogy frissítés után menni fog-e minden ugyanúgy.

Ez is téves. Idén jött ki pl. a 2.4. ami miatt több legacy rendszerünk Apache configját át kellett írni.

- Koherens és letisztult a konfiguráció, nincs az az érzésem, hogy sok különböző ember fejleszti és másképp neveznek dolgokat, esetleg átneveznek dolgokat.

Olyan gány konfigurációt mint az Apache-é, ritkán látni. :)

Bónusz: kevesebb szívás van az Apache-al...

Ha munkaórákban fejezném ki mennyit szívtam Apache-al, és nginx-el, az Apache valahol 100 és 200 között van, az nginx olyan 20 körül.

Shared hosting környezetre van jobb? Ahol sok száz vhostot nem a rendszergazda akarja birizgálni, hanem egy panelt ad a felhasználó kezébe amivel kb. mindent megoldanak? Legutóbb mikor néztem, az Nginx .htaccess-t még nem kezelte. Itt rögtön elvérzett shared hostingban.

( uid_720 | 2014. 12. 24., sze – 17:27 )

Végre kivették az ocsmány vörös csillagot az Nginx logójából.

Fuszenecker_Róbert

( fabian-bros | 2014. 12. 25., cs – 11:49 )

Nem volt egyeb, de Happstack, vagy Ring (mondjuk a java servletekbe ez talan belefert volna, de nem tudtam magam ravenni, hogy raktattintsak)

--------------------------------------
Unix isn't dead. It just smells funny.