Názory k článku Reverzní proxy

"Pokud navíc generování stránky je netriviální úkol, můžete použít reverzní proxy s cachovaním a váš velký aplikační server nemusí trávit svůj drahocenný čas poskytováním statických stránek."
Nemělo tam být spíš jenom triviální??

Jinak ale zajímavý článek...

Nemělo. :) Pokud je generování stránky netriviální, tzn. server nad ní musí více či méně přemýšlet, tak ti reverzní proxy pomůže odlehčit serveru tím, že má statický stránky nakešovaný a tudíž požadavky na ně ho zbytečně neotravujou a může se věnovat složitějším dynamicky generovaným stránkám.

hm, vždycky jsem si myslel, že se _generují_ pouze dynamické stránky, že statické se prostě jenom načtou z disku (paměti) ...

to je taky otazka navrhu aplikace, kdyz se najde aplikace, ktera dejme tomu v php blbou statickou stranku generuje asi takto:

include 'blba_stranka.inc';

tiskni_xhtml_hlavicku('strict'); //dejme tomu
echo 'bla bla bla (alias html kod)';
tiskni_xhtml_konec();

return 0;

tak se neni cemu divit ze server travi spoustu casu generovanim statickych stranek

Článek jsem jenom tak proletěl, přečtu si ho zítra, vypadá to zajímavě. Ale první co mě napadlo: nepomohlo by upgradovat na Apache2? Těch 100 procesů asi bude mít netriviální režii a s dvojkou by jich mohlo být méně, ne? A ten fork() taky nějakou tu milisekundu zabare... Paměť by se možná taky zlepšila.

taky mě to napadlo ...

šla by taková konfigurace, že by server běžel na Apache2 a dělal proxy sám sobě?
co by to v praxi znamenalo?

No, ja bych se spiz pozastavil u toho, proc kazdy thread apache potrebuje 60MB pameti... Tam bude shnily pes.

Protoze: php, mod_perl (mnoho skriptů, ktere zůstavají po zkompilovaní v paměti) mnoho perlovských modulů (konkrétně 300) a např Geo:IP má včetně svojí databáze 10 MB. Taky jsem měl období, kdy jsem si myslel, že to není možné a snažil jsem se zjistit, kde uniká paměť, ale pak jsem to začal počítat a fakt to nejde o moc srazit.
Rozhodně netvrdím, že to je běžná konfigurace. :)

V pripade mod_perl zkompilovaneho jako modul, a neprilis cistych scriptu memory leak je docela bezna vec. Resenim je staticky vkompilovany mod_perl, a 'use strict;' bez vyjimek.

use strict je jasna vec. Stejne tak plna kvalifikace jmen promennych, protoze vytvareni aliasu je velky zrout pameti.
Neni mi ovsem jasne co mate proti mod_perl jako dynamickemu modulu. Sice to je teoreticky trochu pomalejsi, ale rozdil je IMHO stejny jako kernelovsky modul vs. staticky zakompilovane do jadra. Tj. nestoji to za tu tezsi udrzbu.

No, prave. Pokud mam jadro pro konkretni hw a sw konfiguraci, je vhodne (i z bezpecnostnich duvodu) mit cele jadro staticky, bez podpory pro loadovani modulu. Nebo pokud jadro menim za novejsi casteji nez hw/sw. Mimo distribucni jadra, ktera musi mit sirokou hw kompatibilitu, jadra v systemech jejihz vyuziti je ruznorode, nebo kde se casto meni hardware nema modularni jadro vetsiho smyslu.
Troufam si tvrdit, ze staticky zakompilovany modul vetsi udrzbu neudela, stejne se musi updatovat apache jako takovy a je tedy jedno zda skompiluju apache a modul nebo rovnou apache s modulem uvnitr.

A to nedokaze Geo:IP sdilet svoji databazi mezi thready? To musi mit kazdy thread vlastni kopii?
Ono by stacilo to v pameti nasdilet a hned je 1 GB usetren :o)

to já použiji ASP.NET objekt Cache... a mám hotovo :-)

hmm, to ti imho nepomuze zredukovat dobu cteni ze socketu...

Toto je lehce offtopic, neboť článek je o tom, jak odlehčit serveru na nižších vrstvách.
<též lehký OT>ASP.NET samozřejmě nemá patent na cache, třeba v PHP používám objekt Cache_Lite z PEARU, také lze použít cache šablonovacího systému. Podporu cache má každý rozumný framework.</též lehký OT>

Ked spominate perlovske skripty, neskusali ste mod_fastcgi? Proste mat spustenych zopar obsluznych procesov (max.5) na kazdy jeden fastcgi, ktory je na disku.

Dalsi problem moze byt v tom, ze nie je zapnuta query cache v databaze alebo je pouzivana nespravne (updatovanie tabuliek vyprazdnuje tuto cache!). Nevyberaju sa niektore data z databazy zbytocne? Tie data, ktore sa neupdatuju prilis casto, by som fastcgickom vybral z databazy raz, upravil si ich do najvhodnejsej struktury a uz iba pouzival. Dynamicky vytvarane stromovite menu podla tabulky v databaze? Bez problemov ... Pri prvom behu si ho vyrobim a potom uz iba kontrolujem, ci sa nezmenila tabulka.

To uz miri opravdu jinym smerem. A nebojte, tohle mame opravdu dobre pod kontrolou.

Tohle je reseni proti pomalym klientu. Ted si jeste vzpominam, ze na jinem serveru jsem mel spustenou gcache (cache pro P2P sit Gnutella) a nektere hlavicky se od klientu nacitali v i pres 10 sekund!

Mozna sem to v clanku moc nezduraznil (no jak koukam tak vubec), ale pomoci reverzni proxy mate moznost stavet vysoce specializovane servery. Jeden jenom na php, dalsi na obrazky, treti na perlovske skripty... a ta reverzni proxy to bude na ty ruzne servery smerovat podle domeny, pripony, nebo jineho vaseho kriteria.

Nemůžu si pomoct, ale reverzní proxy podle mne dává smysl jen v případě, kdy za ní mám několik fyzických serevrů. Jakmile je jen jeden (a ještě běží na stejném stroji), dá se toho samého efektu dosáhnout dobrým návrhem aplikace (cachovat statická data může aplikace; nenahrávat pro každý požadavek do paměti celých 60MB jde taky udělat v aplikaci; je otázka, zda všechno, co se dělá při požadavku, musí být nutně on-line a nestačilo by třeba dávkové zpracování atd.) Použít v takovémhle případě reverzní proxy lze odůvodnit jedině tím, že chci rychle použít "krabicové" řešení - jinak autor aplikace bude asi lépe vědět, co cachovat, než univerzální proxy.
BTW, podle mne bylo zvýšení výkonu dost ovlivněno náhradou Apache 1.x -> 2.x na "klientské straně", myslím, že co se týče optimalizace procesů a threadů je mezi těmito verzemi velký rozdíl (ale popravdě Apache už moc nesleduji).

Reverzni proxy dava smysl napr. tehdy, pokud chci na tomtez stroji provozovat vedle Apache taky Tomcat, oboji se zvenci muze tvarit tak, ze to bezi na standardnim portu 80.

Na to se pouziva connector (mod_jk) nepotrebuji kvuli tomu revrzni proxy.

Popisovanou proxy znám pod názvem "web akcelárator" (tento název používá Squid). Nevím, na kolik je který termín "standardní", nicméně alespoň se to hodí jako klíčové slovo.

PS. Můj soukromý názor je, že Squid by měl být jako web akcelerátor pro takovéto nasazení lepší -- plyne to z toho, jak zpracovává paralelní požadavky (synchronní I/O multiplexing).

A jak vyřešit ty virtuální domény?
Inspiroval jsem se zde:
http://hysteria.sk/prielom/22/#4

1. Na straně apache použít IP based virtual hosting -- každému virtuálnímu serveru přiřadit jednu IP -- tato IP by měla platnost jen v rámci stroje (libovolný privátní rozsah, za zvážení by asi stál 127.0.0.0/8)
2. Nakonfigurovat dummy interface, pak pro každou IP:
ip addr add dev dummy0 IP
3. Nakonfat squida v "accelerator mode".
4. Zajistit ve squidu převod veřejných hostname na lokálníIP adresy. V tom článku na hysteria.sk je to řešeno pomocí perl redirector, mě napadlo jiné řešení bez nutnosti redirectoru, které by bylo ještě o něco rychlejší -- a to -- rozjet binda pro lokální účely (nebo klidně použít už "rozjetého";)) a přidat mu do konfigurace view asi takhle:
view local {
match-clients { 127.0.0.0/24; };
// překlad veřejných doménových jmen na lokální adresy
}

Co si o tomto řešení myslíte?

No ja bych asi taky preferoval squid, ale apache2 ma vyhodu v tom, ze to muzete pouzit i pro https spojeni, coz na squidu moc dobre nepujde.

Chodit by to melo, ale stejne bych to rozbil radeji na dva stroje, melo by to i vyrazne pozitivni bezpecnostni efekt, protoze exploit na stroji kde je reverzni proxy by neohrozil aplikaci a databazovy server.

On je taky nesmysl nechavat si rozezrat Apache zevnitr pomoci mod_perlu/mod_ruby, kdyz existuje neco jako fastcgi :). To potom muze mit Apache napr. stovky procesu a tucna aplikace ma napr. jen pet.

FastCGI je navic podle mych praktickych testu rychlejsi nez mod_*.

Ale vyvoj temer umrel. Do konference prijdou tri maily za tyden.
Taky mi to prijde jako skoda a fastcgi se mi libi vic nez mod_* (uz jen kvuli 1 proces apache != 1 konexe na externi zdroje - databaze apod.).
Ale pri radove stovkach requestu se zacina chovat podivne a hrozne spatne se to ladi.

Zajímavý názor. Mám všechny požadavky řešené perlovými skripty, tedy neexistuje jiný požadavek v našem ISu, který by šel např. pro statická data (nemáme takové věci). Tudíž každý požadavek potřebuje db. Jak by mohl fastcgi snížit počet potřebných spojení do db proti mod_perlu? Vždyť sdílením by způsobil kolapci session v Oracle, problémy s transakcema apod. Takže jak mi tam ten fastcgi pomůže?

Výkonově je to 14 serverů, na každém z nich ve špičce kolem 400 spojení. Rád si nechám poradit.

FastCGI funguje jako takova proxy naruby. Samotne skripty jsou "za" apachem, ktery funguje k samotne komunikaci s klientem (predavani pozadavku ke skriptu a posilani odpovedi). Tim padem muze tech samotnych skriptu byt radove min nez procesu apache.
V idealnim pripade je reseni proxy+apache+mod_* dosti podobne apache+fastcgi.
Pro blizsi studium to je treba http://www.fastcgi.com/ :-)

To je len taky vtipek nexcem nikoho urazit...

Perverzni proxy? Ano, tu provozuje napr. Eurotel u Data Nonstop a Data Expres. :-)))

http://www.apsis.ch/pound/

Napsal jste, že paměť navíc by nic nevyřešila. To není pravda, ba naopak. Ty 2GB RAM navíc je sice málo, ale i tak by se vám snížila latence u těch HTML hlaviček z 7 ms třeba na 2 ms, protože Vám to tam zpomaluje HDD. To je důvod, proč jsem si domů koupil 1GB RAM a plánuju ještě jeden koupit.

Souhlasim s birkofem, swapujici kompl je na prrrd.

No na apache asi nic nemá, ale zajímávé řešení je také Jeremy Web Server. kumst.net/jeremy