Pryč s reverse caching proxy, ať žije nginx! (diskuse)

[pavlix]

Takže další webserver s podporou proxy. Nebo mi něco uniklo?

Jinak mám dojem, že se i méně časté frameworky častěji realizují na apachi než kde jinde. Tím nechci použití alternativ Apache nijak shazovat.

[al-Quaknaa]

No nevím, takové RubyOnRails jsem ještě na Apachi neviděl (pokud není Apache použit jen jako reverzní proxy a na statický obsah). U TurboGears je tohle řešení (Apache jako reverzní proxy) taky myslím oficiální dokumentované a to už mi přijde o dost rozumější na takovýhle úkol použít lighttpd nebo nginx. Docela jsem se o tohle zajímal (chtěl jsem mít všechno po kupě s Apachem) a vím, že k Apachi to nijak zvlášť přátelské není (respektive jde to, ale v takové podobě, že jestli je tam Apache nebo něco 100x menšího, tak to nejde poznat). Hmm.

[pavlix]

Já jsem toho taky ještě spoustu neviděl.

Ale co půjde na jiných webserverech, půjde nejspíš i na apachi.

A lepší než používat apache jako reverzní proxy... je používat ho jako www server s podporou (například) FastCGI. Většina frameworků fastcgi zvládá.

Pythoní frameworky navíc zvládají WSGI, které má jednak connectory na ledacos včetně FastCGI... a jedna má v apachi samostatnou implementaci (ještě jsem nevyzkoušel, fastcgi mi vyhovuje).

Jinak na lighttpd předpokládám taky používáš fastcgi, nebo ne?

[al-Quaknaa]

Jde mi o to, že v některých předchozích článcích jsem tu řešil. jak mít všechno "pod jednou střechou" - chci, aby se aplikace (ať už PHP, nebo Python nebo Ruby) každého klienta spouštěly pod jeho UID/GID a pak nebyla nutná různá složitá zabezpečovací řešení. K čemuž se FastCGI použít dá, ale nedá se konfigurovat z databáze nebo nějak dynamicky, jako třeba mod_ruid (o tom je taky na blogu nebo v předchozích zápiscích, nejsme si jistý, kdyžtak to najdete googlem). S lighttpd to jde AFAIK napíchnout na MySQL, nejsem si jistý. Neříkám, že něco nejde, ale pokud budete mít Apache + *CGI, tak kde je ten rozdíl proti nginxu nebo lighttpd (které jsou podle benchmarků rychlejší a žerou méně RAM)?

[pavlix]

Nemám přesné porovnání, lighttpd jsem zatím provozoval jen na <200MHz strojích. Nicméně nevím o tom, že by lighttpd umělo nějakou specialitu, co apache nemá. Tzn jo, je rychlejší, ale asi nebude konfigurovatelnější. A s konfigurací fastcgi v lighttpd pomocí jakýchkoliv databází (ať už mysql nebo nějakého plnohodnotného sql serveru) nemám žádnou zkušenost a nikdy jsem o tom neslyšel (což samozřejmě neznamená, že to nejde).

[Messa]

Není FastCGI a reverzní proxy prakticky totéž? U obojího webserver předá požadavek po soketu na nějaký backend (aplikační server). Nebo v čem je FastCGI výrazně lepší? Mě osobně připadá nastavení reverzní proxy jednodušší a průhlednější.

[al-Quaknaa]

No, třeba se přes FastCGI dá ovlivnit, s jakým UID/GID ta spouštěná aplikace pojede - můžete pro každého klienta nastavit zvlášť. FastCGI je v tomhle ohledu lepší a univerzálnější, řekl bych.

[pavlix]

Lol.

To jde stejně u fastcgi aplikací i http aplikací.

Takže v tomhle ohledu je to úplně stejné, rozdíly jsou jinde (viz dál).

[al-Quaknaa]

Jak můžu i HTTP aplikace ovlivnit (ve sdíleném prostředí, kdy jeden webserver obsluhuje více hostů, které mají být odděleny) za jaký UID/GID se bude spouštět? U Apache třeba pomocí mod_ruid, u jiných webserverů nevím, reverzní proxy s tím nemá co dělat. Takže to není ani trochu stejné, jestli budete z webserveru posílat požadavky přes FastCGI nebo jako reverzní proxy - v případě FastCGI můžete ovlivnit věci, které s reverzní proxy ovlivnit nemůžete. A myslím, že v tom mám dost jasno na to, abyste mi neodpovídal "LOL" :/

[pavlix]

Tak, že je je spustíte buď z příkazové řádky, nebo skriptem (napříkad při startu počítače) pod nějakým konkrétním uživatelem.

Myslím, že v tom opravdu máte natolik jasno, že nemá cenu vám odpovídat. To jen, kdyby četl diskusi někdo, koho to zajímá (i když by to musel být úplný začátečník, aby neuměl spustit program pod konkrétním uživatelem).

Teď už se vám nesměju, a moc se za to omlouvám, vím, že se to nemá.

[al-Quaknaa]

Hmm :/ Já opravdu stojím o komentáře a diskusi, jen mám pocit, že kvůli tomu, že jsem napsal blogpost ve stylu, který vám nesedne, se ze mě snažíte udělat blba, což není příjemné asi nikomu, i když máte samozřejmě ve většíně věcí pravdu (nejsou ale v rozporu s tím, co jsem psal v postu). A ke konkrétnímu případu - spouštět Apache pod speifickým uživatelem Vám přijde efektivní? Tak, aby se nepřemnožil a zároveň zvládal vykrýt requesty, by to bylo vážně dost těžké (protože si vydržuje pro každou instanci nějaký počet procesů == zbyteně vyplýtvaná RAM). I pro menší webservery (lighttpd je to plýtvání ve srovnání s tím, jak je efektivní řešení s FastCGI, které udělá suid až potom, co mu přidje request a webserver mu oznámí, na jaké uid:gid má ten suid udělat. V případě nginxu to beru, ten je tak malý, že tyhle funkce nepotřebuje a můžete si jich pustit v systému dostatek bez toho, aby to mělo podobný efekt jako s Apachem. Já ten nadpis snad kvůli Vám ještě přepíšu :D

[pavlix]

Nesnažím se z vás udělat blba. Jestli to tak někdy vypadalo, tak věřím, že si za to můžete sám.

Pokud jde o diskuzi na úrovni... tak se rád budu držet příjemného stylu, většinou se to daří :).

Spouštění apache pod userem není to, co jsem navrhoval. Apache považuju za řešení celoplošné, tzn. jeden nebo rozumně malý počet na server.

Na druhou stranu, FastCGI a HTTP se kromě možnosti dynamického způsobu spouštění (tedy webserver spouští FastCGI procesy) liší jen v protokolu.

Představte si situaci, reálnou (podívejte se třeba na http://xmppid.net/ - jen betaverze). Píšu jednoduchou aplikaci v nějakém programovacím jazyce, která komunikuje s uživateli po jednom nebo více kanálech (v našem případě Jabber a HTTP).

Ta aplikace má několik možností, jak může fungovat:

1) Samostatná webová aplikace implementující HTTP rozhraní přímo dostupná ze sítě.

2) Jako 1, ale dostupná přes proxy server (Apache nebo jakýkoli jiný)

3) Webová aplikace implementující specializovaný protokol pro komunikaci s webserverem (FastCGI, SCGI, ...)

4) Dynamicky linkovaný modul webserveru (který buď sám provádí požadovanou činnost, nebo zajišťuje komunikaci mezi webserverem a interpretem nějakého jazyka)

Možnosti (1), (2) a (3) nativně umožňují aplikaci spouštět samostatně, s právy nějakého uživatele, i bez podpory webserveru (což nevylučuje samozřejmě její použití).

Vedle toho provozuje teda ještě klientské spojení na Jabber server, což je z pohledu webu nepodstatné... ale uvádím to kvůli potřebě persistence.

Asi by se našla i nějaká další, obskurní možnost, jak to provozovat.

No ten nadpis teďka už asi nemá cenu :). A to že mi nesedl blogpost... ještě neznamená, že mi nesedne příští, že ;). Jen bude stát trochu víc úsilí (což je taky jeden z důvodů, proč u mě žádné nové blogposty nevidíte).

[pavlix]

Není to totéž.

FastCGI předá aplikaci všechny hlavičky tak, jak jsou... je to protokol speciálně určený k tomuto účelu.

Webová proxy si s těma hlavičkama trochu hraje.

FastCGI navíc umí více způsobů spouštění aplikace. Buď jí spustíš samostatně (stejně jako bys spustil webovou aplikaci), nebo ji necháš spouštět dynamicky webserverem podle potřeby.

Mě osobně připadá konfigurace FastCGI průhlednější a čistší, zvláště z pohledu bezpečnosti a naprogramování aplikace.

Obojí mi přijde stejně jednoduché, záleží na tom, co se člověk naučil první. Jediné, v čem je FastCGI složitější je to, že právě poskytuje další možnosti navíc, ale ty člověk nemusí využít.

[Messa]

Díky za odpověď. al-Quakna mě nejdřív trochu vystrašil s jeho tvrzením, ze kterého se zdálo, že FastCGI je neporovnatelně lepší, ale pak jsem to pochopil Koneckonců, s reverzní proxy by se také dalo docílit dynamického spouštění aplikace. No, a ty hlavičky... se musí webovce říct, že je za proxy, aby s tím počítala... Nicméně ptal jsem se proto, abych se ujistil, že v tom nemám žádné mezery, nechci nikoho přesvědčovat, že reverse proxy je lepší.

Asi to FastCGI vyzkouším. Zatím jsem všude (ukázky konfigurace v Apache) viděl nějaký dispatch.fcgi a RewriteEngine, který na něj všechno přesměrovávalo a to se mi nelíbilo z estetického hlediska - trochu moc mi to připomínalo věci typu dispatch.php Ale jestli je to best practice a RewriteEngine funguje dobře a rychle, tak OK (na druhou stranu, RewriteEngine používám i pro reverzní proxování, protože to bylo v první odpovědi nalezené vyhledávačem). Třeba v tom nginxu mi konfigurace FastCGI přijde už přehlednější, i když dělá víceméně to samé. Uznávám, že to jsou malicherné důvody, ale mám pak lepší spaní

[pavlix]

dispatch.php neznám.

RewriteEngine je fajn na přepisování adres...

Dá se z něj samozřejmě spouštět ledacos, včetně proxy a redirectů, ale pokud jsou jednoduchý, tak je často píšu přímo.

Já zas někdy kouknu na fastcgi v nginxu... :).

Jinak dynamické spouštění HTTP nepodporuje... musel bys přidávat další mechanismy, FastCGI to přímo specifikuje.

Njn, RewriteEngine je taky z části černá magie.... občas mi nefungovalo něco úplně podle dokumentace. Ale když to člověk otestuje, tak proč ne :).

[pavlix]

Tak už vím, co mi na článku bylo nepříjemné :).

Nebylo to nic technického... jen ten bulvární styl... hlavně nadpisu.

Ono totiž používat reverse caching proxy tam, kde chceme jen reverse proxy je imho blbost.

Takže pokud si někdo blbě zvolí kozu místo vozu... tak to pak jo... pryč s kozou, ať žije vůz! Přecejenom... ta koza je taková pomalá... a zvládne menší náklad, že?

[al-Quaknaa]

Ale já nechtěl jen reverse proxy. "Bulvární" nadpis možná trochu je, původně to bylo v mém blogu, kde si toho dovoluju víc (protože to nikdo nečte), ale prostě to tak je, no. A že bych nevěděl, co si vybrat ... tak to taky nebylo. Ten server už běží delší dobu, nginx je záležitost poměrně nová, řešení s pouze reverzní proxy (Pound) bylo náročnější než řešení s reverzní cachovací proxy, takže tady bych s Vámi dost nesouhlasil ... aneb, ne, já vím, co chci :)

[pavlix]

Njn, můžete se mnou nesouhlasit... ale to je asi tak všechno, co s tím můžete dělat :).

Článek vypadá jako shazování Squid na základě toho, že provádí cachování. Což je ale přesně účel, na který byl squid napsán.

Ne nadarmo zní jeho celý název Squid Cache.

A mam dojem, že na cachovací proxy bude squid asi lepší než nginx.

Navíc si myslím, že i ve squidu se dá cachování vypnout, když by ho člověk nutně chtěl používat jako necachující reverse proxy.

Nginx může být docela dobrý software :), ale vyčítat squidu, že dělá práci na kterou je určen... ;).

[al-Quaknaa]

Ale já jsem se vůbec Squid shazovat nesnažil, ach jo. Jen jsem měl radost, že se mi podařilo rozjet řešení, které není tak obecně použitelné, jako je squid (protože musíte provádět nějakou tu magii s documentrooty) a chtěl jsem se o to podělit. Ale pokud už do sebe rýpeme, tak bych Vám doporučil se mrknout na stránky Varnishe, protože tam se o Squidu dost mluví a také o tom, k čemu byl a nebyl udělaný - Squid jako reverzní proxy primárně dělán nebyl a neodvádí jako reverzní (a to ani cachovací) proxy tu nejlepší práci. Ale to jen na okraj.

[pavlix]

Já jsem squid používal jenom jako klasickou proxy. Jako reverzní většinou používám apache, protože stejnak na té mašině běží. Ale reverzní proxy používám spíš na testování software... finální verzi směřuju spíš k fastcgi.

[Michal Čihař]

A proč vůbec provozovat dva webservery? Nevím jak nginx, ale přes lighttpd není problém provozovat vše.

[al-Quaknaa]

Lidi (klienti) jsou zvyklí na Apache, tím myslím především jeho rewrite. I já bych byl trochu naštvaný, když bych nainstaloval redakční systém s nachystaným .htaccess pro Apache, aby fungovali SEF (Search Engine Friendly) URL a ono to nejelo. A další věci na to jsou navázané. Ale máte pravdu, kdybych nedělal mass hosting, ale jenom nějaký jeden specifický projekt, tak bych Apache už asi nepoužil.

[Michal Čihař]

S přepsáním htacces do lighttpd celkem nemám problémy. Teda zatím jsem u ničeho neměl .

[Josef Kufner]

A uděláš to automaticky, aby si uživatelé ničeho nevšimli?

[Michal Čihař]

Uživatele nehostuju .

[pavlix]

To bude ono... pokud taky ten soft píšeš rozumně, tak žádný rewrite nepotřebuješ, že?

A rewrite jen když se člověku nechce zbytečně řešit různý trvalý (a jiný) redirecty přímo v aplikaci.

[al-Quaknaa]

Jak jinak než rewritem chcete řešit Search Engine Friendly URLs (třeba to co je vidět tady na Ábíčku, ale v PHP aplikacích na Apachi)?

[pavlix]

Nechci :D.

Nechci :D.

A ještě jednou nechci řešit PHP. :) :D

[Filip Jirsák]

A co když je na stránce galerie s 25 obrázky po 30kB – uživatel začne načítat stránku a … buď je najednou server zahlcen (málo RAM), nebo se nedostává na ostatní uživatele, nebo se stránka zase pomalu načítá tomu jednomu

Slušní weboví klienti (prohlížeče, proxy, roboti) mají nastaven limit pro maximální počet souběžných spojení k jednomu hostname, který se zpravidla pohybuje v řádu jednotek (např. můj Firefox má nastaveno 8, což je u něj výchozí hodnota). Může být nastaven vyšší limit pro persistentní spojení (u mne je nastaveno 12), což u modelu process-per-connection může trochu vadit, protože ten proces musí existovat, i když zrovna nic nedělá. Jetty s SelectChannelConnectorem tohle umí řešit tak, že spojení, které je otevřené, ale nic se na něm zrovna neděje, nemá přiřazené ani svoje vlákno, takže těch prostředků vázaných takovým spojením je opravdu minimum.

Taky předpokládám, že většina paměti, kterou zabírají procesy Apache, je ve skutečnosti sdílená paměť – kód Apache a případně modulů. Takže by to s tou žravostí paměti nemělo být zas tak špatné.

[al-Quaknaa]

No nevím, rozhodně když porovnám paměťovou náročnost situací "pouze Apache", "Apache+Squid" a "Apache+Nginx", tak z toho první vychází nejhůř a poslední nejlíp. Co dělají slušní klienti je jedna věc, druhá je, že na různých tunerských stránkách jsou tipy na zrychlení načítání stránek založené právě na zvyšování těchhle hodnot. Ale zas tak moc jsem to nezkoumal, vím jen, že ve srovnání s řešením přes squid mám teď místo loadu 0.3-0.5 asi 0.02-0.1.

[pavlix]

Ty výsledky nejspíš budou při každém použití různé.

Hlavně přímo v manuálu squidu píšou, že se tímhle způsobem používat nemá, takže ten bych rovnou vynechal.

Ale Apache bez Nginx a Apache s Nginx bude podle mě dávat výsledky různé. Podle používání... a podle konfigurace.

Nějaké podrobnější srovnání by určitě smysl mělo.

[al-Quaknaa]

Jo, místo Squidu už jsem poměrně dlouhou dobu používal Varnish, rozdíl značný a problémy popisované v blogu taky úplně neřešil (neříkám, že jsem to od něj čekal, neshazuju cachovací reverzní proxy, prostě to bylo řešení, které jsem použil - to abyste mě zas neobviňoval...). Apache s nginx a bez budu moct brzo otestovat (přijde nový server, takže si budu mít s čím hrát), ale už jen když se nad tím zamyslím, tak by to dávalo docela smysl, ne? Navíc testování v lokální síti, kde přenos větších souborů bude řádově rychlejší (tedy bude muset viset méně procesů Apache) taky úplně neodpovídá reálnému provozu, takže nevím, jak to objektivně otestovat, ale co už ...

Jisté ale je to, že když mám Apache MPM Prefork (což musím mít kvůli mod_ruid a PHP) a _jeden_ proces Apache už bere sám o sobě asi 20x víc než proces nginxu (který se nedělí), tak to bude paměťově mnohem náročnější (pouze Apache) a výpočetně určitě taky (vytvoření procesu a jeho zánik je - i když nejsem ani trochu expert - myslím docela náročné, ne?). Nemám pravdu?

[pavlix]

Mod_ruid a PHP (pokud možno) nepoužívám, takže se mě tohle srovnání netýká.

Navíc... PHP se dá schovat do fastcgi, v případě nouze.

[Messa]

Hmm, to zní dobře. Taky se poohlížím po tom, co by šlo dát před Rails/CherryPy/atd.. Zajímalo by mě srovnání nginx a lighttpd...

[al-Quaknaa]

Na webu nginxu tuším nějaké je, vychází to pokud vím přibližně na stejno, v blogu jakéhosi člověka jsem četl, že lighttpd leakuje a má dost bezpečnostních problémů (což je pravda, ale opravují je).

[pavlix]

Cokoliv, co umí FastCGI, nejlépe. Alternativně můžeš místo FastCGI použít HTTP proxy a třeba CherryPy jako samostatný webserver, samozřejmě.

Cherrypy jsem takhle provozoval, je to docela pěkný řešení.

Zkoušel jsem tuším s lighttpd a apache2, takže porovnání s jinými neposkytnu. S tím lighttpd jsem to pouštěl například na 200MHz Asus wl500gP.

Problémy s tím nebyly, akorát bez CherryPy to jelo znatelně rychleji... navíc jsem se ze zdrojáků CherryPy naučil spoustu pěkných triků :). Doporučuju.

Jo... a KID templates byly taky dost pomalý, i když se mi jinak moc líbí.

[Kvakor]

Cachovaci proxy ale nejspis nebude mit moc velkou ucinnost v okamziku, kdy velka cast provozu nebude cachovatelna - klasickym pripadem jsou fora, kde musi byt kazda stranka cerstve vygenerovana. Takze cachovat se muzou jen CSS, Javascripty a obrazky, a ty stejne cachuje klient. Usetri se jen to prvotni nacteni. Cache by pak mela vyznam spise pro pripady, kde je napr. hodne fotografii ci velkych souboru k downloadu.

Cetl jsem kdysi o reseni pouzitem presne pro podobny priklad - spocival ve spojeni Apache (1.2.x) s jaderneho webserveru (myslim, ze TUXe, bylo to jeste pro 2.4.x jadra a Red Hat), kde byl dynamicky obsah zpracovavan pres Apache a staticky obsah (hlavne fotky) pres jaderny webserver (na jine virtualni IP adrese), ktery posila veci pres sendfile() a tudis s minimalni zatezi a spotrebou pameti (tedy, pokud tam nekdo neda levnou a tupou sitovku, co neumi scatter-gather DMA).

I kdyz, s dnesnimy jadry by by i server v userspace dostatecne vykony (prece jenom je bezpecnejsi mit tyhle veci mimo jadro) a Apache 2.x pouziva misto samostatnych procesu vlakna, tazke by rozdil nebyl zas tak velky.

[David Jaša]

... a Apache 2.x pouziva misto samostatnych procesu vlakna, tazke by rozdil nebyl zas tak velky.

Pokud PHP ještě není thread-safe (a mělo by na tom serveru jet), tak bych to moc nedělal...

[Lukáš Zapletal]

Chapu, ze autor je momentalne nadseny z noveho objevu, ale tohle neni vselek. Dobre zkonfigurovany Apache je dobre zkonfigurovany Apache.

[al-Quaknaa]

Ale určitě, proto taky jásám nad tím, že jsem mohl odstranit Squid/Varnish a nahradit je nginxem, což si myslím že je už jen z hldiska návrhu lepší řešení. Apache je pořád v mém systému nenahraditelný a prozatím tam zůstane a na něj taky nenadávám ... :)

[pavlix]

:)

[al-Quaknaa]

A abychto ještě upřesnil, já nenadávám ani na reverzní cachovací proxy, vyřešila dočasně můj problém, prostě ne ideálně a teď to (myslím) ideální je. Takže ten příspěvek je vpodstatě jen o těch pár posledních odstavcích (hlavně ten konfigurák :D), aby se z toho mohl někdo (až dospěje do podobné situace) poučit. Díky za pochopení :)

[pavlix]

Po vysvětlení chápu :).