HOVD 2015 - Kedvenc http szerver

HUP

apache
56% (458 szavazat)
beépített http szerverek (simplehttpserver, webrick stb.)
2% (13 szavazat)
cherokee
0% (1 szavazat)
hiawatha
0% (4 szavazat)
java servlet container-ek (pl.: tomcat, jetty, ...)
5% (38 szavazat)
lighttpd
6% (50 szavazat)
litespeed
0% (1 szavazat)
microsoft iis
2% (18 szavazat)
nginx
28% (230 szavazat)
thttpd
1% (6 szavazat)
Összes szavazat: 819

( carlcolt | 2015. 12. 14., h – 15:58 )

Szegyennek tartom, hogy meg ennyi ev utan is itt tart az Apache vs nginx. nginx technikailag kilometerekkel jobb es performance-ban is, midnenkinek volt mar jopar eve rajonni.

Mert ha nem mappák lennének, hanem virtuálisan az egész repo lenne valahogy megcímkézve, akkor aztán nagyon szignifikáns különbségek lennének, leszámítva, hogy több kód és bonyolultabban működne az egész... Nem mondom, hogy a legelegánsabb megoldás, de használható.

Nem emiatt tud szívás lenni a mergelés SVN-ben.

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

Óóó... egyrészt a Git teljesen más célra jó, mint az Svn, másrészt az Svn esetén nem állt meg az élet tíz évvel ezelőtt az 1.3.x verziónál... :)

...harmadrészt Git-et adni olyan emberek kezébe, akiknek még az 1.3.x Svn is űrtechnika, hát... nem sok jó származik belőle: https://xkcd.com/1597/

...negyedrészt a könnyű branch ahhoz vezet, hogy ezrével burjázanak a különféle fejlesztési ágak minden kis apró módosításra, aztán pár hónap után már ember legyen a talpán, aki egészen pontosan tudja, hogy melyikben mi van, mi volt, mi hova van merge-ölve és mi függ attól az ágtól, mit ront el...

...a személyes problémám az, hogy ha vannak külön release ciklusban lévő projektjeid, amelyek között a refactor kódot vinne, annak aztán nyoma nem lesz, hogy honnan jött, ki tette oda és mi volt az előélete; illetve különféle metrikákat is nehéz mérni külön repókon.

Se a Git, se az Svn nem a szent grál, ami megoldást ad mindenre, vannak feladatok, amire a Git jobb és van, amire az Svn...

--
https://portal.gacivs.info

Érdekes ez a HTTP szervernél git vs svn hitvita. :)

> 1.3.x Svn is űrtechnika

1.6-ig játszottam vele, az 1.8 nyilván jobb, olvastam a változtatásokat, de nem jött be. Nekem nem az kell, amit csináltak.

> aztán pár hónap után már ember legyen a talpán

Ember vagyok a talpamon. Tudom, hogy a nálunk sok év alatt összejött sok száz branch mi.

> mi hova van merge-ölve

Hát, nagyrészt a masterbe, kivéve az ide-oda portolt hibajavításokat.

> vannak feladatok, amire a Git jobb és van, amire az Svn

Pontosan. És nekem a git jobb.

Ok, én értem, hogy Neked személy szerint jó, de az általam ismert átlagos fejlesztők legalább 90-95 százaléka még az Svn kicsit bővebb használatára is képtelen, a reintegrate már varázslat, a cherry-pick merge pedig valahol a végtelenen túl van náluk...

...ha ők kapnak Git-et, abból nem megoldás lesz a problémákira, hanem ugyanazt a négy parancsot fogják tudni, csak hetek-hónapok múlva úgy fog kinézni a repó, mint amikor pár ezer giliszta násztáncot jár...

...a Git nem egy ultimate weapon vagy egy magasabb szint, hanem más féle problémákra ad megoldást, mint ahogy a NoSQL vs. SQL világ is más problémákat old meg. :)

--
https://portal.gacivs.info

Detto. MSSQL-t is nagyon kedvelem, mert van benne sok-sok szép feature (sok olyan, amit szívesen látnék pgsql-ben is), de összességében a PgSQL egy nagyon kezes RDBMS.

Mondjuk nem lepődök meg összességében a HOVD-n. Legtöbb ember megeszi azt, amit elétolnak, nem néz utána, hogy lenne-e alkalmasabb eszköz a feladat megoldására. (Illetve de, meglepődtem picit, pl. a PHP gyenge szereplésén. )

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

A php azert szerepelt ilyen gyengen, mert sokan meg azt se ismerik itt, csak a bash-t, azt is csak onnan, hogy kimasoltak egy "scriptet" valahonnan ami 3 sorban meghivogat 3 programot parameterekkel.

Belegondolva amugy megszomorubbnak tartom, hogy a nosql-ek kozul is az sql-ekhez kepest semmilyen gyakorlati perforamnce elonnyel rendelkezo mongodb kapott tonnaszam szavazatokat, mikozben azok a nosql-ek, amik tenyleg brutalisan jol skalazodnak sql-hez kepest (dynamodb, solr pl.), azok erosen lemaradtak.

Különösebb belegondolás nélkül, az apache "szabvány" lett, az emberek megszokták, csomó különböző vendor azt szállítja, és nagyjából mindent tud, amit mások. Némi erőfeszítés kéne az emberektől új dolgokat megismerni, ez akadályozza kicsit az új generációt (pl. nginx, hiába mondta el egy csomó ember hogy mennyivel jobb, ha az emberek nem igénylik a jobbat).

--
arch,debian,openelec,android

En nem mentem ennyire messze. A web.config is kb. ugyanazt a szerepet tolti be, mint a .htaccess, a webalkalmazas webszerver oldali konfigjat biztositja, ebbol tudja az IIS, hogy mit es hogyan kell deployolnia. A kulonbseg csak a bonyolultsagban van, az IIS egy komplett appszerver, nyilvan tobb infora van szuksege, mint egy webszerver funkciot betolto Apache-nak. A .htaccess-nek is eredetileg ez volt a celja.

Azonban az Apache - az IIS-tol elteroen - nem mondja meg, hogy honnan kezdodik a webapp, es hol van a vege neki (ezt szimpla webszerverkent nem is igen teheti meg), nincsenek konvencioi - ezert engedi meg, hogy barhol legyen egy .htaccess-ed, ezert kell minden mappat atnyalnia. Raadasul az Apache - az IIS-sel ellentetben - multiplatform cucc, es ha Linuxon lehetne is inotify-vel figyelni, Windows alatt peldaul erre nincs lehetosege.

Az nginx attol tud gyors lenni, hogy semmilyen deployment konfigot nem enged, de ettol maga a koncepcio nem valik ertelmetlenne. Ha azt mondjuk, hogy a .htaccess rossz, akkor a web.config is rossz, meg az osszes deployment leiro is rossz, hiszen mindegyiket ugyanaz a fejlesztoi igeny hivta eletre. Az IIS (meg kb. az osszes Javas-nem Javas alk. szerver) azert cacheli ezeket a leirokat, mert webapponkent csak egy lehet belole, vagy legfeljebb nehany, raadasul fix helyen.
--
Blog | @hron84
Üzemeltető macik

Valaki nemrég itt a hup-on írta, hogy a hely, ahol dolgozik/dolgozott, nginx-et használt. Ő is igényelte volna a .htaccess-t, mire a rendszergazda azt válaszolta, hogy miért is akarja befolyásolni egyszerű "felhasználóként" (fejlesztőként) a webszerver működését.

Az nginx attol tud gyors lenni, hogy semmilyen deployment konfigot nem enged

Csak ennyi a nagy titok?

"miért is akarja befolyásolni egyszerű "felhasználóként" (fejlesztőként) a webszerver működését."

Erre az az adekvat valasz, hogy o egyszeru rendszergazdakent miert is akarja befolyasolni a webalkalmazas mukodeset, amiert a fejleszto a felelos? Hatarmezsgye ez, okkal nem is reagaltam le akkoriban ezt a fajta hozzaallast (ha jol emlekszem), raadasul a rendszergazda mondata teljesen invalid, hiszen nem a fejleszto van a webszerverert, hanem a webszerver van a fejlesztoert, termeszetes igeny, hogy a fejleszto adott keretek kozott befolyasolni akarja a webszerver defaultjait, ha az az alkalmazas mukodesehez nem passzol.

"Csak ennyi a nagy titok?"

Reszben igen, a file scanning-polling nem lete elegge felgyorsitja az esemenyeket, de persze nem csak ez a sebesseg oka, hanem pl. az agresszivebb cacheles is.
--
Blog | @hron84
Üzemeltető macik

Apache annyira multiplatform, hogy már nincs belőle offical Windows build, csak 3rd party összehányt barmolás.

nginx-ből legalább alpha van, fejlesztéshez jó az is.

"Az nginx attol tud gyors lenni, hogy semmilyen deployment konfigot nem enged"

Uuuuuuhm... mivan? Marhára nem attól gyors.

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

Szerencsere nem sikerult jol idezni. De azert skacok, tenyleg ugy vitatkozunk, mint az informatikahoz nem erto egyenek, idezgetunk masoktol sajat komment nelkul? Tessek mar osszevetni az Apache funkciolistajat az nginx-evel. Alapkiepitesben a tizedet nem tudja annak, amit az apache, egy rakas mindent csak fastcgi-n keresztul tamogat, a proxyzas teren is sokkal kevesebb feature-t tamogat alapbol, mint az Apache (cookie rewrite, body rewrite, stb), illetve vannak dolgok, amikre felkeszitheto, de sokkal bonyolultabban, raadasul van, amit eleve csak ugy tudsz megcsinalni, hogy az rontja a teljesitmenyet. Amit tud, azt nagyon jol tudja, es nagyon jo teljesitmennyel is csinalja, de en azt gondolom, hogy azzal, hogy kevesebb feature-t tamogat, sokkal kevesebb kodra van szuksege, igy emiatt sokkal gyorsabb is tud lenni.

De persze ha valaki megmondja, hogy miben tevedek, azt megkoszonom. De az, hogy csak idezetekkel dobalozunk, az kicsit az ovira emlekeztet.
--
Blog | @hron84
Üzemeltető macik

Nem vagyok egyáltalán expert ezen a téren (sőt). De amennyire olvasmányélményeim alapján értem, az nginx működésének az alapja más, mint az apache esetében (event-based meg ilyen kulcsszavakra gondolok).

Hangsúlyozom, nem vagyok egyáltalán expert, de az a kijelentésed, hogy azért gyorsabb az nginx, mert nem nyálazza végig a könyvtárakat .htaccess-ek után kutatva, elég meredeknek tűnt (tehát ha a .htaccess támogatást kikapcsolnánk, akkor megkapnánk az nginx-et?). Ennek hangot is adtam, de úgy tűnik, túl burkolt volt, mert félreértetted - az agresszív cache-re nem írtam semmit.
Ezzel a mostani hozzászólásoddal se értek egyet, azaz nem hiszem azt, hogy ha az apache-ot csak annyira használnánk, amit az nginx alapból tud (azaz az apache le lenne "butítva" az nginx szintjére), ugyanaz lenne a sebesség.

A sebesség-különbséget (hozzá nem értőként) inkább a két szoftver alapjainak különbözőségében látom (vagyis inkább vélem látni). Illetve amennyire (szintén olvasmányélményeimre támaszkodva) tudom, inkább úgy fogalmaznék, hogy valamiben az apache, valamiben az nginx a jobb/gyorsabb.

Szóval ennyit tudok mondani. Kérem, kapcsolja ki!

Azért te se szoktad túl sűrűn elővenni a józan paraszti eszet a kamrából, ugye?

"nem hiszem azt, hogy ha az apache-ot csak annyira használnánk, amit az nginx alapból tud (azaz az apache le lenne "butítva" az nginx szintjére), ugyanaz lenne a sebesség."

Persze hogy nem. Az Apache, pont azért, mert annyi feature-t támogat, szükségképpen egy csomó mindent sokkal bonyolultabban old meg, mint az nginx, akinek nem kell ennyi mindenfélére felkészülnie. Emiatt az Apache nagyon sok mindent kevésbé optimálisan old meg az nginx-hez képest, mert neki több felhasználási esetre kell felkészülnie, nagyságrendekkel több követelménynek kell megfelelnie, mint az nginx-nek, attól függetlenül, hogy pontosan a konfig alapján neked mi a szándékod. Az Apache nem játszhat barchobat minden inditaskor, hogy ugyan a fejlesztonek/uzemeltetonek mik is az eredeti szándékai.

Ugyanakkor az is igaz, hogy az Apache sebessége javítható (önmagához viszonyítva), ha kikapcsolod belőle a felesleges funkciók nagy részét, és pl. ugyanugy FastCGI-n keresztül préseled a PHP-t, mintha nginx-ed lenne. Nem lesz belőle egy nginx-es sebesség, de jelentősen gyorsulni fog.

A másik nagy probléma, hogy amikor az Apache-ról meg az ő sebességéről beszélgetünk, akkor rengeteg dolgot kellene konkretizálni, pl. hogy milyen MPM, milyen modulokkal, stb. Olyan, hogy az Apache sebessége, önmagában nincsen, nem értelmezhető, szemben pl. az Nginx-szel, ahol a core nem cserélhető (mint Apache esetében az MPM-ek), illetve nem, vagy nem teljesen moduláris felépítésű (bele lehet forgatni modulokat, de nem dlopen-nel töltögeti be őket, mint az Apache).
--
Blog | @hron84
Üzemeltető macik

A ribbon önmagában szerintem egy használható ötlet (vannak előnyei is, pl. kitölti a rendelkezésre álló helyet, ha van megfelelő számú elem), ha nem akarjuk túlmisztifikálni, akkor egy adaptív méretezésű toolbarokból álló tabos felület.

Az már más kérdés, hogy annak kéne letörni a kezét, aki a default beállításokat összerakta (különösen a 2013 ALL CAPS-es nevekkel, azért azért extraként az összes térdkalács is jöhet...), az tényleg gáz. (LO-nak viszont oldalsávja, az én ízlésemnek még az is túl sok dolgot tartalmaz [elég kellene, hogy legyen egy stílusválasztó :)], viszont a szélesvásznú képarányokkal és az általánosan álló doksikkal valamivel szerencsésebb az oldalt kitölteni, mint a Ribbonnal a tetőt)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Szerintem meg ezerszer inkabb a ribbon, mint a toolbaros ize. Sokkal használhatóbb és legalább lehet tudni, hogy mit tud a szoftver és mit nem.

Egyetlen helyen visszalépés szerintem, az pedig az, hogy pl. a színpalettát nem lehet kihúzni egy popupba, ha sokat kell színezni hírtelen, akkor jól jönne, csak ez ugye ellentmond a koncepciónak. (Illetve az újabb Officek legyen minden ugyanolyan fehér, mint a dokumentum, hogy ne lehessen látni a határokat designjáért még kijár a faszkorbács... Ami nem romlott el, azt nem kellene megjavítani...)

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

Nekem erről pont ellentétes véleményem van. Apache configja hol ini akar lenni egyenlőségjelek nélkül, hol meg XML, egy egy rák az egész, ahogy van.

Meglepetések terén meg pont az Apache-ban voltak számomra igen furcsák, mikor a defaultot kellett volna konfigolni és nem valami vhostot.

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

Sok más területen is megérdemelne az apache egy rendes kövezést! ;-)

Az nginx nagyon-nagyon jól beleillik a unix filozófiába. Pont azt csinálja, amire való:
Egy kis http (?) "proxy".
Ha kell, akkor egy fájlt szolgál ki mint célt, és ezügyben tudod befolyásolni a működését.

Ezt gyorsan, okosan, kis overhead-del tudja tenni, kis memória-footprinttel, hatékonyan.
Nem véletlen hogy könnyen megugrották vele a c10k problémát.

Ha meg valami dinamókus tartalom kell, akkor a megfelelő technológián átpasszolja a kérést olyan socketre, ami erre való,
és azt meg végezze az, ami tényleg erre lett kitalálva (pl. php-fpm).

A konfig szintaxisára egyszer kell csak ráérezni az nginx-nek.

Anno, mikor az apache-ból sok szinten lett elegem, elkezdtem átállni lighty-ra.
Tetszett. A szintaxisa is tetszett. Jobban mint az nginx-é.

De mivel, minden de facto az nginx felé ment, ezért elkezdtem azt is megtanulni.
Szóval, nekem az nginx elsőre utálatos konfigja felé átállást megkönnyítette, hogy ütközben egy lighttpd-t is kipróbáltam, és szeretem.
Aztán eljön az a pont, amikor már elvan az ember az nginx-el is magában.

Amúgy meg htaccess konverziókra, nem tökéletes, mert "gondolkodni" nem tud helyetted, de kiindulásnak: anilcetin
Amikor már a webfejlesztő érthetelenre elburjánzott try&error-al fejlesztett sokadik htaccess-ét konvertálod nginx-re...
Egy idő után rutinból konvertálsz! ;-)

Az nginx messze van a unix filozofiatol imo. :P

C10k-t nem volt nehez megugrani. Anno volt egy tucat httpd ami megugrotta, meg nginx elott (az en thyom is, pedig akkor meg annyira se tudtam kodolni, mint most:P).

A szintaxisat lehet meglehet szokni, de attol meg nem fogom szeretni. Szerencsere evente kb egyszer kell hozzanyulnom, igy nem zavar nagyon. Viszont igy hozzaszokni sem lehet, tehat mindig jon az ujratanulas.

htaccessel meg nem foglalkozom, igy ez a resze szerencsere irrelevans szamomra.:)

--
|8]

( Celtic v | 2015. 12. 14., h – 19:39 )

Szinte mindenhol nginx-et hasznalunk, de en jobban kedvelem az apachet. Szoval apache-re szavaztam, holott tudom, hogy nginx jobb.

--
http://www.micros~1
Rekurzió: lásd rekurzió.

( manfreed (nem ellenőrzött) | 2015. 12. 20., v – 23:48 )

Lighttpd. Senki? Hogyhogy ilyen kevesen? :)

Dobogos, mit akarsz meg? :)

Egyebkent nem rossz, meg vagyok vele elegedve, egy low-end vm-en meg hasznalom is (meg Rpi-n is be volt allitva amig be nem doglott az az SD kartya). Ennek ellenere nem ra szavaztam, nem o az elsodleges.

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

Legalabbis mindketto a C szintaxisra probal emlekeztetni. Viszont ami nekem nem jott be, azok az otletszeru ponttal valo elvalasztasok, nem jottem ra a logikara, hogy hol kell pont es hol alahuzas. Valahogy nem volt egyben a dolog. Az nginx ilyen szempontbol nekem sokkal attekinthetobb.

Mondjuk nekem az is szerepet jatszik az ellenszenvemben, hogy akarhanyszor szembe jott, nagyon idiota modon szet volt vagva a konfig, ez nem a Lighty hibaja, egyszeruen nem voltam elegge otthon benne ahhoz, hogy ertsem, miert ugy volt szetvagva, ahogy, csak bennem ez negativ nyomot hagyott.
--
Blog | @hron84
Üzemeltető macik