Názory k článku
Test webových serverů Apache, Nginx, LiteSpeed, OpenLiteSpeed, Caddy a Lighttpd
-
Stanislav SchattkeStříbrný podporovatelTakže to vlastně otestovali v default konfigu kde nejspíše byl Apache nestaven v prefork modu. Pokud by ho přehodili na event tak myslím by ty čísla vypadal úplně jinak.
-
A hlavně to testovali na HW ekvivalentu, který je tak z roku 1999:
Hypervisor: Proxmox
Operating System: Debian 12
CPU: 4 sockets, 1 core total
RAM: 2048MB (Limited due to LiteSpeed free trial restrictions)
Storage: Standard virtual disk with sufficient space for testing
Network: Bridged network for direct access to VMs2G RAM?
-
Jenže ten test netestovat funkce proxy (nginx před mikroslužbama), ale testoval servírování statických souborů hromadě klientů. A ten setup je na toto použití úplná hloupost. Pokud chci servírovat hromadu souborů hromadě klientů, tak se hodí mít io cache. Takže na server, který chce servírovat 10tis velkých souborů za sekundu, tak by bylo vhodné, kdyby se alespoň ty soubory vlezly do io cache. Takto vlastně nevíme, jestli ten kontejner běží na stroji, který to má v cache a hlavně tohle chování vůbec není garantované. Takže test definovaný "málo paměti, vps, nějaké úložiště a tady máte výsledky" je celkem o ničem.
Zcela nepřekvapivě se každá firma snaží o co největší užitnou hodnotu za vynaložení co nejnižších nákladů.
Jasně, ale tak potom je otázka, zda vůbec potřebuje webserver. Já jsem se při této zprávičce spíše zamyslel nad tím, kdy jsem naposledy a proč instalovat webserver. Protože už hezky dlouho mají všechny jazyky ve standardní knihovně http server. Od mého přechodu na python jsem vše servírovat pythonem (ano, na nginx jako https proxy) a v golangu už komplet, bez nginx. Takže pokud nějaká šetřivá firma chce uspořit ram (protože ta stojí miliardy a vůbec nelze za 10tis kč koupit 128GB RAM do desktopu), tak si to napíše v něčem jako rust a servíruje to rovnou ze služby. A pokud má náhodou více než jednoho klienta, tak před to strčí něco jako CloudFlare.
Proto mi test výkonu na tak malé VPS přijde vlastně jenom divný.
-
Já psal mikroslužby ale v našem případě jde o statické soubory (nemá smysl to rozebírat). Je jich ale pár, ne sto giga, to ano. Nesmysl to není. Prakticky každý test a každý benchmark je umělý.
Jestli servírujete všechno vestavěnými HTTP servery přímo do internetu, jste blázen. Ty HTTP servery jsou od toho, aby si to od nich vzalo odlazené a zabezpečené proxy typu nginxu (doplňte si váš oblíbený software). Nemluvě o tom, že když máte webové aplikace nebo malé webové aplikace obecně, dnes to je dávka pár malých statických souborů. Které nějak přes HTTP ven dostat musíte. Vyrobit kontejner s nějaký nginxem je to úplně nejprimitivnější co můžete pokud máte další kontejnery třeba s API hned vedle udělat. Pochopitelně by šly strkat někam do statických hostingů, CDN a tak dál, ale to jenom komplikuje deployment jako celek a homogenitu prostředí celkově.
A psal jsem vám o VPS. Železo je otravné na správu a pro mnoho firem dávno zbytečné a vlastně i nespolehlivé. Proč si asi myslíte, že mají VPS a kontejnery takový úspěch.
-
Jestli servírujete všechno vestavěnými HTTP servery přímo do internetu, jste blázen.
Všechno ne.
Ty HTTP servery jsou od toho, aby si to od nich vzalo odlazené a zabezpečené proxy typu nginxu (doplňte si váš oblíbený software).
Tohle platilo tak před 10 lety. Dneska to má aktuální tls apod. Ten proxy lze před to strčit vždy, ale na menší přístupy (tj pro celou ČR) to funguje. Není žádný důvod to nenasazovat.
K tomu zbytku, jsem admin, tohle dělám 15 let, není třeba mi to vysvětlovat. Virtualizaci profesionálně od 2008. Před tím pár let jako pomůcka na univerzitě.
A psal jsem vám o VPS. Železo je otravné na správu a pro mnoho firem dávno zbytečné a vlastně i nespolehlivé. Proč si asi myslíte, že mají VPS a kontejnery takový úspěch.
Moc nevím k čemu tohle má souviset. Jestli k té velikosti paměti, tak virtuálku s 96GB RAM jsem instaloval někdy před 10+ lety. Takže VPS vůbec nemusí automaticky znamenat malá velikost (málo cpu, málo ram, špatný storage). Takže pokud dneska někdo potřebuje servírovat hromadů souborů hromadě klientů, tak si celkem bez problémů může pronajmout virtuální server s 256GB RAM a nvme úložištěm s garantovaným io. Vůbec nic z toho, co jsem napsal, nesměřovalo na fyzický HW o který se musí firma, která to nechce dělat, starat.
-
Řeší ten server třeba i Slow lorris?
Řeší ho by default už jen způsobem implementace. Zrovna tohle nebyl moc dobrej příklad. Když jsem se díval, jak na slow loris reagoval třeba nginx (který se slow lorisem neměl žádný problém), tak nad rámec doporučení "nemusíte dělat nic" ještě umožnil blokovat počet spojení per IP. Tohle všechno defaultní webserver v golangu samozřejmě umí. Jedním parametrem transportu lze definovat počet spojení per ip, takže na psaní je to vlastně kratší, než ten zápis v configu nginxu. :-)
Tyto servery spíše předpokládají nasazení na reverzní proxy.
Tohle je ale fakt už celkem zastaralé uvažování, protože už hezky dlouho se tyto prog jazyky používají na mikroslužby a komunikaci přes rest. Což není nic jiného, než osekaný http. Takže obávat se nějaké nebezpečnosti, když už je to dávno v milionech služeb vystaveno na internet je tak trochu opožděná obava. Nehledě třeba na to, že na interním webserveru běží i taková gitea.
Takže, když tohle zrovna řešíme pod touto zprávičkou, tak pokud někdo na mikro vps nepotřebuje zrovna servírovat statické html (tam se věci jako nginx nebo lighttp velmi hodí), tak pro webové služby na takto malém kontejneru se úplně bez problémů hodí interní webservery ve standardních knihovnách. A pro daný účel je to ještě rychlejší, než ten nejrychlejší webserver, protože se prostě ušetří jedna proxy vrstva.
-
-
Což není nutně špatně. Když dnes vezmu nginx, udělám minimální konfiguraci, kde mu jen řeknu co má poskytovat, je to tak pět řádků kódu a práce na patnáct minut i když to nedělám denně? A stejně tak s Apache. Takže testovat defaultní konfiguraci má smysl. Stejně, jako jiný test, tedy nedefaultní konfigurace. Nevylučuje se to.
-
To nemusi byt pravda. Delal jsem podobne testy asi pred 5 lety (sezralo to nekolik stroju ve farme jako generatory, dedikovany virtual jako server na staticky obsah, paralelni pocet session byl vyssi jednotky az nizsi desitky tisic http/1.1 spojeni, a uz si nepamatuju absolutni cisla (mozna neco kolem 70kreq/s ale ruku do ohne za to nedam u nginxu versus 40kreq/s u maximalne vyladeneho apache, uz nevim jestli mpm_worker nebo mpm_event).
Takze jestli se od te doby apache hodne nespravil, tak rozhodne nejde o prefork.
-
Takto je to síce nič nehovoriaci, ale aspoň dačo naznačujúci test. Ak by sa kdekoľvek odchýlili od defaultu v čomkoľvek... Viete si predstaviť tie reči? Toto mali nastaviť tak a tak. Druhý by mal zas presne opačný názor. Proste sa tomuto vyhli a ak má aj tak niekto nejaké reči, tak odpovedia, že všetko bolo v defaultnom nastavení. Ruky umyté.
-
V tom testu mi chybi http.sys
V mem testu http.sys vsechny strcil do kapsy...https://learn.microsoft.com/en-us/aspnet/core/fundamentals/servers/httpsys?view=aspnetcore-9.0
ab.exe -n 1000000 -c 10000 https://myserver/test
ab.exe -n 20000 -c 1000 https://myserver/test -
a je to tu zas :)
jak uz to bylo receno mnohokrat ... neni vubec zadny problem napsat http server ktery umi servovat staticke stranky a bude v tom nejrychlejsi na svete. Problem je zustat nejrychlejsi a nabidnout take nejake dalsi funkce.
Zadnej z tech serveru neumi to co Apache, kdyby jo, take by byli pomalejsi a mozna i vic nez on. -
Chápu správně že všechny ty testy jsou přes http/1.x (je to http://, a ten wrk pro "multi-threaded real-world load simulation" má otevřené issue na podporu http/2)? Má pak takový test vypovídací hodnotu při reálném provozu z browserů? I pokud je před tím proxy tak zase nevidím smysl v testování mnoha současných klientů.
-
Na Nginx nedám dopustit, ale je pravda, že Apache ho může v menším loadu dohnat s mpm_event a při vypnutí .htaccess. Pak už ale nezbývá, moc důvodů, proč ho používat. Za posledních 15 let jsem Apache použil jen v případě, že byl nutný SAML.
Mimo Nginx v poslední době ještě nasazuji pro méně náročné aplikace Caddy, protože má dobrou integraci se vším možný, vcelku bezproblémovou podporu moderních protokolů a mnoho jde v něm dost věcí automatizovat. Další benefit pro mě je, že je jednoduché pro něj psát vlastní moduly v go a nenadělám tam tolik chyb, jako kdybych to psal v C pro nginx . Až zase budu potřebovat SAML, tak použijí Caddy.
Testoval jsem i LS/OLS, ale výkon byl srovnatelný s nginx. Trochu může těžit z vlastní integrace s PHP přes lsphp, ale FPM mi přišlo stabilnější při vyšší zátěži. Také považuji jejich marketingové postupy za docela nekalé, když vydávají mnoho jimi sponzorovaných benchmarků za nezávislé. Ty vyhrávají často kvůli LScache pro wordpress, a proti tomu stojí konfigurace bez zapnutých obdobných technologií i když jsou možné, protože "default"...
