Re: lug-bg: SQUID

[vlk@email.domain.hidden (Vesselin Kolev)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<p><p><em class="quotelev1">>
<em class="quotelev2">> > 2. Kolkoto poveche saitove ima v internet, tolkova po razliata e
<em class="quotelev2">> > krivata na interesa. T.e. malko sa tezi saitove, za koito ima goliama
<em class="quotelev2">> > poseshtaemost ot edna i syshta mrezha, podlozhena na transparent
<em class="quotelev2">> > proxy v ramkite na makym otrez ot vreme.
<em class="quotelev1">>
<em class="quotelev1">> Tova e taka, shto se otnasia do ISP-tip mreji, t.e. vsiakakvi useri, NO
<em class="quotelev1">> DALECH NE E TAKA PRI FIRMENI MREJI !!! T.e. matematichnia ti model bi
<em class="quotelev1">> triabvalo da sledi i "entropiata na userite" ;-)

Ne samo pri ISP. Pyrvo pri ISP pone v bylgaria e malyk procenta na tezi,
koito izpolzvat cache-serverite na dostavchika. Pravia tova na osnovata
na prouchvane na logove na 3 bylgarski ISP.

Prouchval sym i proxy statistikite na universitetski serveri.

Kogato se pravi podoben analiz e dobre da se nameri edna normirana
velichina, koiato da e predstavitelna za izpolzvaneto na cache. Tazi
velichina e bezrazmerna. Kato takava nie sme izbrali otnoshenieto na
broiat otgovori ot cache kym obshtiat broi TCP zaiavki kym cache-a.
Tazi velichina triabva da ima oscilacionno povedenie i chrez 
extrapolacia mozhe da se nameri nai-veroiatnata stoinost okolo koiato
tia oscilira.

Primerno za ISP tazi velichna riadko nadhvyrlia 0.1 (t.e. 10%). Za 
universitetski mrezhi e i po-malka, > 0.05 (t.e. > 5%). Pravili sme i ocenka
na firmeni mrezhi. Tam efektivnostta zavisi ot broia mashini. Pri malyk
broi mashini ne mozhe da pravish ekstrapolacia na velichinata, spriamo
povedenieto na koiato pravish analiza. Izmamno e tova, da se misli, che
kato edna mrezha e firmena, to informaciata, koiato shte byde iztegliana i
cache-irana shte byde ednorodna (uslovie za efektivnost na proxy).
Otchasti prihinata za slaboto izpolzvane na cache e, che veche browsera
e cache-iral obekta pri sebe si, i pone e taka za nai-chesto poseshtavanite
saitove. Druga prichina e, che mnogo ot sluzhitelite iztegliat failove, golemi
po obem, koito drugi ot potrebitelite v localnata mrezha niama da iztegliat
povtorno ot cache. T.e. te ne tegliat HTML documenti s pridryzhavashtite
gi butoni i formi, koito sa osnoven obekt na cache.

Shto se kasae do entropiata na potrebitelite... Az po-skoro bih govoril za
entropia na poseshtavanite adresi. Dori ne bih govoril za entropia, zashtoto
e nerealno da opredeliame velichina svyrzana s broi microsystoiania,
realizirashti edno makrosystoianie, pri uslovie che ne mozhe da se definira
adekvatno poniatieto mikrosystoianie pri mnozhestvo, elementite na koeto
sa zaiavki i niama kriterii za ocenka na zaiavkata kato teglo...
Po-skoro adekvatno e da se govori za razpredelenie po povtorenia. Sirech,
definira se edna velichina, koiato ukazva chestotata, s koiato dvama
razlichni potrebitelia biha izteglili edin i sysht obekt ot sait. Tova e
sluchaina velichina. Posle mozhesh da vzemesh edno predpolagaemo
razpredelenie i s kriterii na Kolmogorov-Smirnoff da vidish adekvatno li si
izbral razpdelenitelnata funkcia ili ne. Ako izboryt e adekvaten, to mozhesh
da rabotish napravo s razpedelitelnata funkcia na veroiatnostta, a ne s
izvadkovata diskretna funkcia i da pravish generalni izvodi.

Kazano s dumi prosti: Max. efektivnost na cache shte tyrsish tam, kydeto
ogrmnoto bolshinstvo potrebiteli gledat MNOGO edni i syshti saitove.
Tova go niama i vyv firmite.
<em class="quotelev1">>
<em class="quotelev2">> > Po princip proxy v momenta mozhe da byde efektivno SAMO
<em class="quotelev2">> > (obyrnete vnimanie na tova), ako se izgrzhdat sibling mrezhi i se
<em class="quotelev2">> > raboti na principa na spodelenia cache. Taka se uvelichava
<em class="quotelev2">> > veroiatnostta edin keshiran obekt da byde izpolzvat poveche ot
<em class="quotelev2">> > edin pyt.
<em class="quotelev1">>
<em class="quotelev1">> Abe i v tozi sluchai ne e mnogo iasno, shtoto de-fakto e vse edno ot
<em class="quotelev1">> tazi gledna tochka dali shte e edno proxy s OGROMEN masiv i OGROMEN broi
<em class="quotelev1">> useri ili mnogo proxy-ta s po malko useri.
<em class="quotelev1">>

Samo taka izglezhda. Sledvai algorityma Heap Sort i shte vidish, che
po-goliama skorost shte postignesh chrez poveche sibling sysedi,
otkolkoto s edno po-goliamo proxy. Prost fact e, che sortirovkata na
goliam cache i tyrseneto na elementi e po-neefektivno ot razmnozhavaneto
na tyrseneto po po-malki cache-ove vyrhu poveche samostoiatelno
izpylniavashti algorityma systemi. Razbira se sibling sysedite e nuzhno
da se svyrzani s byrza vryzka.

<em class="quotelev2">> > Imaite predvid, che statistikata sochi, che edin proxy-server e
<em class="quotelev2">> > tolkova po-efektiven kolkoto poveche klienti go polzvat. Ima edna
<em class="quotelev1">>
<em class="quotelev1">> mi, da - kak ne se setih ;-)

Ima i dolna i gorna granica. Dolnata granica e zavisima ot stitisticheskoto
razpredelenie na zaiavkite. Gornata e tehnologichna i dyrzhi
smetka za byrzinata na tyrsene na obekta, t.e. byrzinata na dostyp do
bazata ot danni s cache-iranite obekti.

<em class="quotelev1">>
<em class="quotelev2">> > Dalech po efektivno reshenie v tazi posoka e da se pravi IP managirane
<em class="quotelev2">> > na traffica po napravlenia i po resursi. Tazi rabota obache iavno ili
<em class="quotelev2">> > ne e po interesa na mnogo hora, ili prosto niamat kapaciteta ot znania
<em class="quotelev2">> > za da ia izvyrshat.
<em class="quotelev1">>
<em class="quotelev1">> Sega puk az shte ti kaja, che ima edno poniatie, koeto mu se vika
<em class="quotelev1">> "Content Filtering", a ti mi kaji kak shte go napravish s IP menagirane.
<em class="quotelev1">>

Naistina ima takova poniatie. Ama ti primerno kak si predstaviash da
preglezhdash hiliadi documenta v sec. za edin natovaren server??? 
A ako failyt e kompresiran? A ako e kodiran? 

Shto se kasae do IP managirane, imam predvid traffica da se razdeli na
prioritetni grupi. Naprimer mozhe mnogo lesno da se localizirat adresite
na free hosting operatorite v adresnite prostranstva v BG. Traffikyt kym i
ot tezi mrezhi da podlezhi na razlichno managirane ot tozi za chuzbina.
Primerno edna firmena mrezha, mozhe da limitira traffica za bylgarskite
adresi s free hosting taka, che tova da ne prezhi na traffica za mrezhi,
koito se izpolzvat za sluzhebni celi. Prez denia se ogranichava..., a 
pred noshta se puska svobodno teglene (koito e syobrazitelen izpolzva
shedule i tegli prez noshta, za da ne prechi na horata prez denia).

Ima i drugi fokusi. Ako edin IP adres nadhvyrli niakakv kvota.. popada v
po-baven kanal. No pyk zapazva byrz kanal za saitove svyrzani s
rabotata mu (govoria za firmeni mrezhi). Vyobshte ima mnogo i raznoobrazni
varianti, koito predlagat goliama gyvkavost.

  Pozdravi
     Vesselin Kolev
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+bdxi+48lZPXaa+MRAjupAJsHKmTAp+JIc6SjIMR0CxOhgHVVZACfYB3B
5WIPYWRAoemkoTaP71lLcFk=
=40uk
-----END PGP SIGNATURE-----

============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================