Nejpoužívanějším web serverem je odteď Nginx

Správně by se ale mělo uvést, že nginx se velice často používá jako reverzní proxy pro více "schovaných" apachů, takže reálná čísla budou trochu jiná.

Je to tak, zrovna včera jsme o tom mluvili na školení. Tyhle statistiky jsou dělány z toho, co je vidět v internetu, jinak to ani nejde. Na druhou stranu on i Apache umí fungovat jako reverzní proxy, mám takové ve správě (zákazník to chtěl), takže to bude vždycky jen určitý omezený pohled na realitu.

Vím jak se to měří, ale chybou článku je, že tohle neuvádí.

Apache je mega moloch, kterej trpí tím, kolik toho umí a proto není (v porovnání s nginx) tak rychlej a proto si nginx našel svoje místo.

Do zprávičky jsem to doplnil, díky.

Ano, Apache je mega moloch, proto pouziva modularni architekturu. Nginx moloch neni, proto pouziva jednu binarku do ktere je vsechno nakompilovano (a co v ni neni, to uz nemas moznost pozdeji dle potreb dynamicky natahnout)...

To už není pět let pravda, Nginx umí načítat moduly.

v ČR má jedna banka F5, ale tváří se jako nginx, tipuji, že to nebude jediný případ, dky se vydávám za někoho jiného.

Ještě větší problém pak nastává v případě CDN, které se používají čím dál častěji. Je vše přes Cloudflare bráno jako nginx nebo jako jednotlivé web servery v pozadí? (Ano, tenhle žebříček to dává k nginxu kvůli Cloudflare).

Souhlasím s tím, že tenhle žebříček je naprosto špatně, v titulku mluví o "web serverech", ale podle metodiky žádné web servery vlastně neměří a měří pouze proxy/edge servery.

F5 bych řadil mezi ty „jiné varianty odvozené z nginxu“. Speciálně u té F5, což je produkt vlastníka nginxu, takže myslím není pochyb, co běží uvnitř.

> Ano, tenhle žebříček to dává k nginxu kvůli Cloudflare.

Já na tomhle konkrétním grafu vidím "Cloudflare Server" zvlášť a dost vysoko (15–20%).

> If we combine all these Nginx-based technologies, they occupy a very impressive 52.4% of the market.

Vladimír Čunát: to je pravda, mají tam CF samostatně, blbě čtu, díky!

Nginx se používá jako reverzní proxy z nouze.

Apache se dostal do těžkých problémů. Implementoval spoustu funkčností bez ohledu na dopad na výkon a bezpečnost. A co se stalo? No, lidi to začali používat, světe div se!

Apache se dá nastavit na velmi slušný výkon, ale musí se obětovat zhůvěřilosti. Nginx zhůvěřilosti ani neimplementuje. Namátkou složité rewrite, htaccess.

Provozovatelé by rádi přecházeli na nginx kompletně, ale zatím nejsou aplikace přizpůsobené, aby nevyžadovaly Apache a jeho obezličky. Lepší se to jen pomalu, protože programátoři často houby vědí o http serveru a co je potřeba pro efektivní provoz.

Provozuji obvykle reverzní nginx a za ním je aplikační apache a aplikační nginx. Ty se obvykle ještě dělí na oddělené instance, kvůli bezpečnosti. Co jde, obsluhuje i aplikačně nginx. Co nejde, musí zastat apache.

Statický obsah může servírovat rovnou nginx, nezpomalený pravidly, která jsou (někdy) pro statický obsah k ničemu, ale tady se musí opatrně. Admin musí znát zároveň i aplikaci a vyhodnotit, jestli je takové řešení bezpečné a neobchází nějakou aplikační logiku.

Trend růstu nginxu naznačuje, že čím dál víc adminů si toto uvědomuje.

Webový vývojář, který houby ví o HTTP serveru by svou práci neměl než se dovzdělá vůbec dělat. Vždyť to je přece základ. Mně, mimochodem, dost překvapuje, že se tak děje až teď. Apache httpd jsem na projektu neviděl ani nepamatuju. A nějak mi tedy fakt nechybí.

Např. s čím se setkávám. Vývojář je agentura, která pro zadavatele dodává WordPress. Tj. vůbec to není vývojář v pravém slova smyslu, jen umí nainstalovat systém podle návodu a když server nepracuje podle návodu (třeba kvůli nepodpoře .htaccess), tak k zadavateli jde informace, že všichni to umějí, jen tenhle server je na nic... Zadavatel není ochoten to vůbec řešit (od toho má agenturu), a agentura není ochotná opravdového vývojáře nebo admina platit (nemá na to budget, a i kdyby ho měla, proč by ho dávala dál). Pokud už "vývojáře" platí, tak maximálně aby dodělal nějakou "cool feature" pro zadavatele.

To samé platí o zhoršujícím se výkonu s rostoucími daty, nebo při souběhu požadavků: vždyť mi to funguje rychle na mém počítači, tak mi neříkejte, že SERVER může být pomalejší...

To je realita.

Nechci vam kazit iluze ale kazdych 5 let se pocet programatoru zdvojnasobi. To nejsou ani stredoskolaci ci programuji. Kdyby netusili jen co je HTTP byla by to parada.

Webový vývojář, který houby ví o HTTP serveru by svou práci neměl než se dovzdělá vůbec dělat. Vždyť to je přece základ. Mně, mimochodem, dost překvapuje, že se tak děje až teď. Apache httpd jsem na projektu neviděl ani nepamatuju. A nějak mi tedy fakt nechybí.

Njn, nemal by... Realita je vsak taka ze staci ze si niekde odpatla 3 roky a zrazu je z neho senior a idemu len velmi tazko vysvetlit v com je chyba :D

Proc by mel truhlar vedet jak funguje uvnitr motor v jeho pile?

Proc by mel truhlar vedet jak funguje uvnitr motor v jeho pile?

Protože potřebuje vědět, kolik toho smí nařezat naráz, aby nezadřel motor. Kdy má na chvíli vypnout, aby to vystydlo. Kdy má kam kápnout olej nebo co namazat vazelínou. Jak se má chovat k listu pily, aby vydržel. Když to dělat nebude, bude mít majitel dílny zbytečná vydání a bude stát zrovna ve chvíli, kdy musí pod pokutou dodat zakázku.

Nebavíme se o tom, že má znát motor, ale musí znát jeho principy, limity a údržbu a vědět, jaká pila se hodí na jaký typ práce.

Njn, preco by mal vediet uzivatel webu ako to funguje v servri? Miesto neho to MUSI vediet ten co tu aplikaciu naprogramoval.

To by bylo všechno hezké, ale někde se to ten webový vývojář musí naučit a mezitím neumřít hlady. Neříkám, že se má všechno střílet od boku, ale nějaké rozumné výchozí nastavení a návod typu "Get started quickly and safely" by na spoustě míst bohatě stačilo. Obecně, trochu víc pokory ve smyslu, že zrovna náš zájem nemusí být pro všechny okolo prioritou by ve společnosti neuškodil. Ono by to třeba vedlo k tomu, že by lidé skutečně přemýšleli, jestli ještě přidat tady tu další volbu, která 99% případů jen komplikuje. A ano, není povinností vývojářů nginxu nebo jakéhokoliv jiného projektu dělat cokoliv pro zjednodušení a pochopitelnost technologie. Na druhou stranu, taky od ostatních lidí čekáme, že nebudou házet odpadky ani do vlastní zahrady i když je to jakoby jejich pozemek a nic by nám do toho nemělo být. Jedná se o jakousi slušnost. Bohužel spousta technologií vypadá jako 30 let staré smetiště, kde je spousta věcí "protože by se to ještě mohlo někdy hodit", které mezitím spolehlivě otrávilo podzemní vodu.

Celý ekosystém kolem webu je neskutečně komplikovaný, každá věc se konfiguruje úplně jinak, typicky se dokonce používá vlastní názvosloví a syntaxe. Upřímně jenom skutečně rozumět TCP je už poměrně oříšek. HTTP v aktuálně tak 3 verzích po TCP a nově i UDP, QUIC, TLS a různé hlavičky a další věci celou věc dále dost výrazně komplikují. No a to jsou všechno jenom takové pseudo-předpoklady pro dodání skutečné hodnoty. Zákazník totiž většinou neplatí za znalosti HTTP(S), ale za to, že mu pojede web a vyřeší tím zase svoje problémy.

Pokud bych přirovnal webového vývojáře k řidiči automobilu, tak bych řekl, že dokud nebudete mít přečtený zákon o provozu na pozemních komunikacích, tak nesmíte za volant. Třeba řídit se čtením zákona nenaučíte vůbec. Všichni víme, že realita je prostě jinde, tak buďme prosím shovívaví k tomu, že ne pro každého webového vývojáře je znalost HTTP serveru podstatná.

"Provozovatelé by rádi přecházeli na nginx kompletně, ale zatím nejsou aplikace přizpůsobené, aby nevyžadovaly Apache a jeho obezličky. Lepší se to jen pomalu, protože programátoři často houby vědí o http serveru a co je potřeba pro efektivní provoz."

Súhlasím, ale s tým že síce Apache je gigantický superhumus, a áno nginx je ohodne lepší, no stále by som povedal že nginx sa nedá zaradiť medzi skvelé riešenia HTTP serverov. Ale chápem že to bolo vytvorené pre PHP programátorov, čož už PHP samo o sobe je dobrý humus. Pre mňa skutočný HTTP server je len riešenie postavené na Node.js alebo Golang (prípadne ešte pár iných ale tie sú na trhu minimálne rozšírené).

No, apache ma spoustu výkonnostních problémů v prefork mpm. Což je bohužel jediný civilizovaný způsob jak spustit PHP. FPM má bugy (při rychlém respawnování workerů občas chcípne master) a oproti server statusu apache prakticky nemá monitoring. Takže za mě je docela dobrá kombinace nginx + php-apache, pokud nemáte před tím třeba envoyproxy. A proč php? Typicky proto, že ve firmě je v něm už spousta webů napsaná.

PHP-FPM ma prece take status, dost podobny tomu od apache

To je samozřejmě nesmysl, PHP-FPM funguje úplně normálně a nemá problémy s velkou zátěží. Spravuji řadu serverů pod velmi vysokou zátěží a FPM se chová zcela příčetně a rozhodně master nekolabuje. Samozřejmě má i vlastní monitoring se stavovou stránkou (status).

Nejde o zatez, jde o recyklaci workeru. Pokud mate nastaveno maxrequest na nejakou neprilis vysokou hodnotu, protože historicky nějaká část php leakovala paměť a prijde tam vysoký traffic, tak race condition pri sbírání ukoncenych workerů, nebo tak něco shodí php fpm. Alespoň ve verzi 7.1 stále byla, nerevyresena jiz od 5.4, nebo kdy na ni nekdo poprve narazil. Pak jsem to prestal sledovat. Koukam, ze nejnovsi fpm uz ma docela lisky full-status. Ovsem my co bezime na debianu stable a oldstable takove vymoženosti jeste nemame.

Já teda cpu nginx jako reverzní proxy před všechny Apache pod mou správou a už si to neumím představit jinak. Je to velmi robustní a rychlý server. Svého času jsem ho měl i jako proxy pro imapový server a taky vše v pohodě. IIS jsem nikdy nepřišel na chuť, to bylo spíše za trest to spravovat... ;-)

Můžu se zeptat, co ty Apache dělají? Měl jsem za to, že Apache většinou servíruje statické soubory, je tam nějaká PHP aplikace nebo dělá reverzní proxy pro nějakou aplikaci za ním. To vše bez problémů zvládá i nginx. Používáte Apache ještě na něco jiného, máte tam nějaké moduly? Nebo něco z výše uvedeného provozujete na Apache?

Statické soubory servíruje nginx a je na něm zakončeno SSL. Apache má v sobě modul PHP (pro ty PHP aplikace) a v některých instalacích ho mám prakticky jen kvůli .htaccess pravidlům, ač jsem dříve zkoušel koketovat s https://winginx.com/en/htaccess.

kto by to iniciativne prerabal z apachu na nginx ked je to uz odladene riesenie?

Taková změna vám sice okamžitě nic nedá, ale jednodušší setup pomůže při migraci na novou verzi systému.

Ja. Povoleny htaccess je iops brzda. Akorat preucit vyvojare resp. nasmerovat vyvoj, aby nevyzadoval tunu rewrite je orisek...

Nginx php neumí. Umí maximálně fastcgi, ale php-fpm má bugy (při rychlé rotaci workerů sletí master proces) a oproti apache serverstatus, který vypíše které url který worker zpracovává, prakticky nemá monitoring.

Je to nesmysl, ve vlákně výše vám to vyvrátil pan Krčmář. Mohu jeho tvrzení potvrdit z vlastní mnohačetné zkušenosti.

Nginx je super ako ssl endpoint a reverse proxy nad apachmi, tomcatmi a IIS.
Jenoduchostou mu tam moze konkurovat asi len pound.
Mam aj instanciu nginxu na windows stroji kde tento proxuje RDP do windows-only VNPky, takze sa na RDP dostanem aj z linuxovej masiny.

S Apachem to je takový začarovaný kruh. Hostingy, což je, hádám, valná většina webů z té statistiky, ho nemůžou úplně dropnout kvůli mod_rewrite a proč by se vývojáři snažili se bez toho obejít, když to podporuje "každý" hosting. Naštěstí to je spíš doména PHP. Ostatní jazyky mají tendenci komunikovat nějakým buď svým nebo rovnou HTTP protokolem. Osobně mi je proti srsti fakt, že webserver načte soubor a nad ním spustí interpretr jak kdyby to byl nějaký šablonovací systém. Prakticky to nemá žádnou výhodu, ale nevýhody z toho úplně trčí.

Webserver nenačítá php soubory, jenom zkontroluje cestu a podle toho volá příslušný modul (pro php volá mod_php). Soubor (a všechny includy) si otevírá až php, ne přímo webserver.

A ten modul běží v čem? Pokud jste to někdy nastavoval, tak víte, že s mod_php vám na serveru poběží jen procesy Apache. Je tedy validní říct, že Apache načítá PHP kód ze souborů a prohání ho embednutým interpretem.

Však taky mod_php používají dnes už jen zastydlíci. I opičky opisující z internetových kuchařek využívají Apache jako proxy do FPM.

Děkuju pěkně. FPM mi nevypíše co který worker a jak dlouho dělá. Apache jo. To se pak chyby v php aplikacích ladí výrazně lépe. Navíc php-fpm, jak jsem psal výše, má bugy. Holt do apache_mod_php bylo za ta léta vloženo více úsilí a je to znát.

Však PHP má také svůj server. Ostatně mám pocit, že při vývoji se to také čím dál více prosazuje. Než pracně instalovat Apache, tak jen nad projektem příkazem spustit PHP server.

Apache a mod_rewrite je jen ze zvyku. Funguje to, tak proč to měnit ;)

Ten PHP server není snad ani pro produkční nasazení, ne? Nebo o čem je řeč?

kdyz uz mam v dockeru pripravenou produkci tak co je na tom tak slozityho to samo pouzit lokalne?

Pokud jde o korporaty tam je to casto uplne obracene. Kdejaka Java ma vlastni HTTP server (Tomcat/Jboss/Web­Logic) popr. primo framework obsahuje HTTP server. A nic z toho co Apache poskytuje neni potreba. Nginx(Plus) snadno resi vse co loadbalanceru muzete pozadovat.