SQUID kérdés

 ( orpheus | 2005. július 4., hétfő - 11:48 )

SQUID kérdés

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A köv. kérdésem adódik a squid cache proxyval kapcsolatban:

Hogyan gyorstárazza a dinamikus oldalakat? Képes ilyenre?

Egy példa: van egy sokgépes MS-windows hálózat, és le kell tölteni az aktuális MS biztonsági frissítéseket. Márpedig egy ilyen manővernél az van, hogy az aktuális MS kliens explorere kap egy dinamikus titkosító kulcsot + session azonosítót, és ezek után kezd bele az érdemi munkába, vagyis a frissítési csomagok letöltésébe.

Ezt miképpen tárazza a squid? Ezek után mennyire lesz elérhető a többi kliens számára is?

Hy
A helyetben ilyesmit keresgélnék neten:

refresh_pattern -i microsoft.com 12960 100% 12960 override-lastmod

Ja meg a squid confjaban...

Hello

Ha csak a frissitéek sebességét akarod növelni, akkor növeld meg a SQUID-ban tárolt objektumok nagyságát (maximum_object_size).
Ez jelenleg 20MB nálam, és drasztikusan megnő adott gépre a letöltés.
(Természetesen növelni kell a cache méretét is, és a gyorsaság nem
jelentkezik azonnal)

Üdv
LG

Sokgépes MS frissítéshez meg érdemes saját frissítő szervert beüzemelni...

Köszönöm a tippeket, de azt hiszem, nem volt teljesen egyértelmű a kívánalmam.
Az MS frissítést csak példa képpen hoztam fel. Ennél az a kérdéses, hogy a csak és kizárólag egyedi hozzáférést kapott gép által letöltött (és itt főleg titkosított!) csomagok a squidben is letárolódnak-e, és ha igen, a többi gép számára is hozzáférhetőek-e???
Ahogy tudom, a squid akkor készült és akkor volt igazán hasznos, amikor még csak statikus weboldalak léteztek többnyire. Azonban az elmúlt években azek kihaltak, és a dinamikus sewsite-ok vették át a teret.
Nos hát => ezekkel is boldogul a squid??? Ugyanolyan jó hatékonyságú-e, mint régen???

A dinamikus oldalak tele vannak kisebb nagyobb kepekkel is es ezeket is tarolja a squid. Altalaban egy weblap mereteben a kepek eleg sokat jelentenek, ezeket mindenkeppen tudja cache-elni, de minden olyan oldalt - legyen az akar dinamikus - amire a webszerver azt mondja hogy ugyan az (asszem 302) tudja tarolni es azt visszaadni.
Amugy titkositott kapcsolatot (https) alapbol felesleges proxyn keresztul kuldeni mivel ugy sem tud vele mit kezdeni. Eppen azert titkositott, hogy csak a kiszolgalo szerver es a kliens hasznalhassa az adatokat.
Amugy a gyorstarcsazas ugy mukodik, hogy keep a live kapcsolatot epit
a squid a szerverrel es nem kell a kliensnek felepiteni a teljes kapcsolatot eleg csak a squid-hoz kapcsolodnia.

Mas:
webszerver uzemeltetoknek pedig hasznos lehet savszelesseg csokenntes celjan transzparensen tomoriteni az adatokat (amit erdemes).
leheto legyegyszerubb modja PHP-s kornyezetben a ob_start("gz_handler") fuggveny meghivasa a script elejen

Köszönöm, én is így tudtam. De reméltem, hogy esetleg van valami általam nem ismert funkció, ami képes lenne ilyen feladatot ellátni.

[quote:0ac4876749="zsalab"]
Amugy a gyorstarcsazas ugy mukodik, hogy keep a live kapcsolatot epit
[/quote:0ac4876749]

Ehhez annyit: sehol nem beszéltem gyorstárcsázásról. Gyorsítótárazásról (cache) beszéltem.

Volt valakinek olyan problémája, hogy ha a cache könyvtár elérte a megadott korlátot, akkor a Squid nem működött?

[quote="orpheus"]Köszönöm, én is így tudtam. De reméltem, hogy esetleg van valami általam nem ismert funkció, ami képes lenne ilyen feladatot ellátni.

[quote="zsalab"]
Amugy a gyorstarcsazas ugy mukodik, hogy keep a live kapcsolatot epit
[/quote]

Ehhez annyit: sehol nem beszéltem gyorstárcsázásról. Gyorsítótárazásról (cache) beszéltem.[/quote]

nem sokat aludtam az ejszaka, mar olvasni sem tudok :-)

Szép álmokat :-) :-) :-)

Sziasztok!

A Squid.confomban a cache_dir-nek beállítottam a cache könyvtár méretkorlátját. A korlát működik, azonban ha eléri a cache könyvát mérete ezt a korlátot, akkor ahelyett, hogy a cache-t elölről újraírná, a logban kiírkálja azt a hibát, hogy betelt a rendelkezésre álló terület, és a Squid következő újraindításakor nem indul el (ez nagy baj). Persze, hogy betelt, én adtam neki korlátot! Mit lehet tenni, hogy ne hibaként kezelje a korlát elérését, hanem kezdje elölről a cache-elést, felülírva a régi cache-adatokat? vagy mit érdemes végeztetni vele? Jelenleg beállítottam a cronban, hogy bizonyos időközönként ürítse a cache-t. Ez a pillanatnyi hibát megoldja, de így megszűnik a cache gyakorlati haszna (a szűrésen kívül). Mit tegyek?

Alapesetben az lru van beállítva a cache- és a memory_replacement_policy. Alapesetben hogyan kezeli a Squid azt a helyzetet, amikor a cache_dirben megadott korlátot eléri a cache könyvtár mérete? Mit csinál a cache-eléssel?

Pontosabban, ha nekem nem purgálja a cache-objektumokat, lés az alap beállításon hagytam a replacement-et, akkor annak mi az oka? Mit csinál a proxy azon kívül, hogy kiírja a naplófájlban, hogy a tárhely elérte a korlátot? Mi történik, ha már egy létező cache mellé generálok egy újat a "squid -z"-vel?

Szerintetek is jó ötlet az időszakonkénti cache-törlés?

[quote:51939ff865="lacika"]Szia,

Csak egy tipp: próbálj meg más cache_relacement_policy -t alkalmazni.
Próbáld meg az "alap" lru -t. Egyébként most milyen policy van beállítva?
Meg nézd meg a store.log és cache.log tartalmát. Abban lehet találsz valamit.
A cache törlése nem feltétlen a legjobb megoldás,mert ahogy te is írtad, így a squid elveszíti az "értelmét".

Laci[/quote:51939ff865]

Köszi! Én semmilyen relacement_policy-t nem állítottam be. Miket kell beírni a squid.conf-ba? Semmi erre utalót nem leltem benne. És hogyan tudom beállítani az alap lrut? A store.log és a cache.log semmi különöset nem mutat, illetve a cache.log akkor igen, amikor eléri a korlátot (ahogyan írtam.)

Szia,

Csak egy tipp: próbálj meg más cache_relacement_policy -t alkalmazni.
Próbáld meg az "alap" lru -t. Egyébként most milyen policy van beállítva?
Meg nézd meg a store.log és cache.log tartalmát. Abban lehet találsz valamit.
A cache törlése nem feltétlen a legjobb megoldás,mert ahogy te is írtad, így a squid elveszíti az "értelmét".

Laci