LAMP++

Amit egy Linuxos webszerverből (ésszerű határok közt) ki lehet hozni az itt megtalálható.

Kapcsolódó oldalak

Címkék

apache (8) backup (1) blog (1) cache (1) chroot (4) cms (1) daemontools (2) ddos (1) djb (1) dns (2) dos (1) email (1) geoip (1) google (2) ip (1) kvm (1) lamp (1) linux (1) mail (1) mysql (4) nginx (3) pdumpfs (1) php (8) pound (1) proxy (2) regcheck (1) seo (2) shell (1) shorewall (1) snapshot (1) spl (1) ssl (1) statisztika (1) szerver (1) thttpd (1) tinydns (1) tűzfal (1) ubuntu (1) virtualizáció (1) wordpress (2) Címkefelhő

Utolsó kommentek

  • aFoP: Írtam bash szkriptet ami a fent letölthető hu.csv-ből legenerálja az összes hálózat-címet, így már... (2014.04.26. 10:51) Magyar IP tartományok
  • Oszi: A JPEG support -hoz nem árt még ez is: --with-jpeg-dir=/usr/include (2009.06.08. 10:52) PHP fordítás
  • Oszi: @bagoj ur: OK, össze szedem magam és blogba vésem amit tudok. Hamarosan... (2009.03.05. 20:18) Virtualizáció KVM -el
  • Utolsó 20

Feedek

Mire jó a web proxy?

2008.08.20. 23:27 Oszi

Mire is lehet használni egy web proxy -t?

  • Tud cache -elni. Na, ez az amire én nem szoktam használni. Ugyan vannak nyilvánvaló előnyei a dolognak, de egyrészt eléggé erőforrásigényes, másrészt néha problémás. Elég jól ki kéne találni, hogy mit érdemes cache -be rakni (túl nagy és dinamikus dolgokat általában nem).
  • Ad egyfajta biztonságot, mivel elrejti azt ami mögötte van.
  • A kért tartalom függvényében más-más szerverekhez továbbithatja a kérést. Erre jó példa a statikus dianamikus tartalom szétválasztása. Itt a statikus tartalmat külön erre a célra kihegyezett gyors webszerverrel szolgáljuk ki, mig a dinamikust pedig egy másikkal. Ez a fő ok amiért én proxy -t használok.
  • Akár load ballance -t is lehetne csinálni vele.

Amit web proxy -nak szoktak használni az tulajdonképpen Reverse Proxy.

Többféle megvalósítás létezhet, én most itt 4 általam már kipróbált müködő példát említek:

  • A proxy megvalósitható Apache segítségével. Itt célszerű 2.x -es Apache -ot választani, mivel annak mod_proxy modulja jobb. Mögötte a dinamikus tartalmat (PHP) 1.x -es Apache szolgálja ki, míg a statikus tartalmat egy thttpd. A thttpd nem a legismertebb (és már nem is fejlesztik), de tulajdonságai alapján (kicsi, gyors, jól konfigurálható), teljesen megfelelő.
  • Az előbbi példán lehet olyat csavarni, hogy ha a proxy már úgyis 1 Apache, akkor akár ki is szolgálhatja a dinamikus kéréseket, és ilyenkor csak a statikus dolgokat kell átirányitani egy thttpd -nek.
  • SSL -t igénylő megvalósításánál (bár nem ezért, mert természetesen az Apache is tud SSL -t), használtam proxy -nak a Pound -ot. Mivel ez valóban csak 1 proxy, ezért kell mögé statikus tartalom szerver (thttpd) és dinamikus tartalom szerver (Apache) is.
  • Végezetül a legújabb, és általam legjobbnak tartott megoldásnál a proxy és statikus webszerver funkciókat egyben egy nginx látja el, és csak a dinamikus tartalmat továbbitja a mögötte lévő Apache -nak.

Hogy miért nginx? Szerintem erre a feladatra ő a legjobb. Statikus webszervernek még szóba kerülhetne a lighttpd, de az nginx abban is a legjobbak közt van.

Végezetül még talán megéri megemlíteni, hogy mire is jó ez az egész? Teljesítmény szempontjábol sokat hozhat a konyhára. 1 tipikus weboldal 1 dinamkus tartalombol és ahoz tartozó jóval több statikus tartalomból (js, css, képek) áll. Ha ezeket külön a célra szakosodott webszerverek szolgálják ki, akkor az gyorsabb lesz. Nem mellesleg, az nginx memóriaigénye lényegesen kevesebb az apache -énál.

3 komment

Címkék: apache proxy nginx thttpd pound

A bejegyzés trackback címe:

https://lamp.blog.hu/api/trackback/id/tr64625269

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

bagoj ur 2008.09.07. 23:08:19

Szerintem meg lighttpd proxynak, PHP backendnek és statikus tartalomnak is. Mindent tud, terheléselosztást is; és nem kell 3-féle szervert feltenni és a konfig szintaxisát észben tartani...

Oszi · http://inews.hu/ 2008.09.08. 15:55:47

Egyszerűbnek egyszerübb az tény.
Volt néhány dolog ami a lighttpd ellen szolt:
hostingfu.com/article/nginx-vs-lighttpd-for-a-small-vps

bagoj ur 2008.09.11. 14:56:32

Hát, a mod_rewrite tényleg nem egyszerű (vagy mondjuk ki: elég szar), de én stabilitás- és memóriagondokkal nem találkoztam, pedig most is folyamatosan megy sok helyen. Persze elhiszem, hogy valakinek előjött ilyen, én csak az 1.4.17-nél szívtam a kód futtatásos biztonsági hibával.
süti beállítások módosítása