A web proxy szervered átlagos találati aránya

Címkék

0-5%
5% (17 szavazat)
6-10%
2% (5 szavazat)
11-20%
4% (14 szavazat)
21-30%
4% (12 szavazat)
31-40%
2% (5 szavazat)
41-50%
1% (4 szavazat)
nagyobb mint 50%
3% (9 szavazat)
nem tudom
79% (246 szavazat)
Összes szavazat: 312

Hozzászólások

Gondolom nem erre gondolsz es nem is a legoptimalisabb bizonyos esetekben, de Zorp-al is megvalosithato ehhez hasonlo. Igazi elonye dinamikus tartalomszolgaltatas cache-elesenel van, mivel eleg bonyolult algoritmust lehet ra illeszteni a python-nak koszonhetoen.

Eppen J2EE alapu web kiszolgalas gyorsitast tesztelgetek vele. GET es POST keresek. Elso korben biztatoak az eredmenyek. Szelsoseges esetekben akar 200x-os gyorsulas is tapasztalhato. Termeszetesen ehhez szukseg van egy igazan lassu backend kiszolgalasra, amit ugyebar megfelelo programozassal lehetne segiteni....

Udv,
Viktor

Ja. A szavazás nem véletlen, mindenféle különösebb optimalizáció nélkül körülbelül 20% cache hit ratio-t nyom itt egy SQUID egy 6Mbit/sec-es csíkon. Ahol több GB-os napi forgalom mellett talán már nem mindegy, hogy a forgalom kb. egyötöde a helyi cache-ből jön-e vagy sem. Főleg ahol ilyen korlátozott az internet hozzáférés.

--
trey @ gépház

Már miért ne használna? A cache-elés mellett tartalomszűrés, logolás, stb.
Na igen, én is leginkább erre használom, dansguardian mellett.
Vírusírtó mellett pl. egyes gépeken tiltom a .hu-n kívüli tartalmakat. Mondjuk vicces, hogy az E-on honlapja com-os domainen van, aztán nem jön be a magyar honlap.
A squid logját nézve meg egész jó statisztikát kapok, milyen lapokat látogatnak.
Mondjuk a cache-elés eddig nem érdekelt, de a cikk alapján próbálkozok majd.

Nekem nem kell mondanod, én az ISP-k helyében csinálnék transzparens proxys csomagokat, és olcsóbban árulnám őket. Kliens oldalról (hacsak nem vagy rákényszerítve, azaz tiéd a választás) csodálkoznék azon, aki még ilyet használ...

suckIT szopás minden nap! A fogfúró a villám ellen

Elegge nem egyertelmu a kerdes, hogy most darabra, vagy byte-ra szol...
Es egy "nem bonyolitom az eletet http proxy-val" valaszra is sokan szavaztak volna talan. ;)

Én meg elgondolkodtam rajta, hogy akarom bonyolítani ennyire, de nem akartam. Ezért úgy döntöttem, hogy megkérdezem az átlagot. Azaz a rendelkezésre álló adatok alapján mondj egy számot, hogy kb. mennyit segít.

Például egy sarg-ban az IN-CACHE érték teljesen megfelel.

--
trey @ gépház

Régen 10-20% volt amíg kellett, most már pazarlunk.

Nálam 5% alatt van. Mondjuk van egy parent proxy is.
Ja: a találati arányt poresszel, vagy poresz nélkül nézzem? :)

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

a céges squid-et valamikor 1998 tájékán konfiguráltam, anno. brutálisan nagynak számító 3GB-os cache_dir-rel. akkoriban a net 64k bérelt vonal volt, a szerver pedig Pentium 166.

a rendszer túlélt néhány hardvercserét, ma dual xeon csücsül alatta, sokmegabites dróttal. a squid-et becsületesen upgrade-elgettem, a konfighoz viszont nem nyúltam. bevált.

most megnéztem a hit rate-et: 24%.

mindenki transzparensen keresztülmegy rajta.

Cache information for squid:
	Request Hit Ratios:	5min: 55.8%, 60min: 53.8%
	Byte Hit Ratios:	5min: 32.0%, 60min: 25.8%

Ez alapján böktem egy 41-50%-ot, nem tudom, melyikre lettél volna kíváncsi.
A napi átlagok is a 60 percre hasonlítanak.

4000 authentikált felhasználó, 2x50 Mbit.
Naponta kb 60-100 GB forgalom.

Privoxy fut. A web kb. 5-10%-a biztosan reklam, szoval hasrautesre kb. ennyi a talalati arany. Log nincs.

--
"Digital content is not a tangible good and should not be subject to the same liability rules as toasters." - Francisco Mingorance, BSA

ezt ajánlják chrome-hoz adblock helyett.

nagyon szép, de pl. hosszabb fájlfeltöltéseknél gyönyörűen megdöglik "connection timed out"-tal.

vagy pl. egy image hosting-nál, ahol a kép path-jában szerepel az "ad" könyvtár (nyilván szét vannak osztva, aa, ab, ac ... mappánként), remekül kiszűri. biztos lehetne whitelist-ezni, de valahogy emiatt nincs kedvem beleásni magam a konfigja szintaxisába.

hirtelen ez a két példa jut eszembe. a lényeg, hogy nem a legjobb, főleg ha !powerusereknek is fel akarnám tenni.

szerintem.

Egy picit off, bár ez is proxy kérdés...

A proxy cache-ében tárolt tartalomért ki a felelős? Értem ez alatt, hogy nálunk a munkaállomásokon található tartalomért a dolgozó a felelős. Ha letölt, telepít programokat, azt a saját felelőségére teszi. De ha a letöltést a proxyn keresztül végzi, akkor igen nagy az esély arra, hogy a letöltött tartalom a cache-ben marad. Ilyenkor jogi szempontból ki a felelős a cache-ben tárolt állományokért?

A felhasználó? - Logokból elvileg visszakereshető melyik gépről töltötték le...
A rendszergazda? - Ő a felelős a szerver üzemeltetésért, a szerveren tárolt tartalomért...
Senki? - A squid-et mint feketedobozt kezelik, a cache-ében tárolt tartalomért senki sem felelős, hisz az csak egy plusz átjáró az internet és a felhasználó gépe között, nem egy "file kiszolgáló". Ha van valami gond, akkor csak a felhasználót és a gépét veszik elő.

------
Az akarok lenni ami akkor voltam, mikor az akartam lenni ami most vagyok...

Valaki kiirhatna reverse proxy hit rate szavazast is, forward proxyt nem hasznalunk, reverset annal inkabb. Ott atlagban 95-96% cache hit rate van.

Squid, transzparens mód:

Report period: 09.Mar 08 18:03:03 - 27.Jul 09 16:18:50

A cache-hit elég vegyes, a hup.hu -ra 70%, az ubuntu.hu -ra 90%, a mogorvamormota valahogy megkapta a 100%-ot [ez fura mondjuk, mert rendszeresen olvasom], persze van rengeteg 0%-os is, amik lehúzzák az eredményt, de ha a valóban, naponta látogatott oldalakat nézzük akkor kb. 80-90%-körüli érték a reális.

Így az eredmény: 32.97%