Firefox 4.0 navyšuje velikost diskové vyrovnávací paměti

nijako.
moze vsak byt rychlejsie nieco stiahnut znova z webu ako prehrabavat X vela mega cache na pomalom disku.

pri dnešných terabajtoých diskoch je to skôr málo. a čo sa má prosímťa prehladávať v Cache? cache je tu od toho aby sa to práveže načítalo rýchlejšie, stiahnúť niečo z netu a načítať to z disku je dosť veľký rýchlostný rozdiel.

blizzboz: problem je pristupova doba, nez se disk natoci, muzete mit data ze site uz stazena v ramce.
huhuhu: to s tim hledanim je pi*ovina, protoze normalne se dotaz na existenci souboru odbavi pomoci dcache (soucast jadra) bez jedineho pristupu k disku.

Aha, takže než něco najít v cache na mém disku (řádově desítky milisekund) je podle vás rychlejší poslat dotaz po internetu na server, ten to najde ve své cache a data mi pošle? Asi toho o internetu a HW moc nevíte :-) Předpokládám, že když si vybíráte procesor, tak také chcete nějaký model, který nemá cache, protože je přeci rychlejší číst instrukce přímo z paměti místo zdržovat se nějakým hledáním v cache :-) Zkrátka, hrubě jste nepochopil fungování cache. Zjevně si to představujete jako změť souborů na disku a vyhledávání v ní si představujete jako zkoušení každého jednoho souboru, zda to není on. Jenže to není cache a ani by to nefungovalo (jak chcete zjistit, jestli je to ten správný soubor?) Základem cache je asociativní tabulka, která si pro každý klíč pamatuje hodnotu. Tedy například si pamatuje že „http://root.cz/o­brazek.gif“ je uloženo v souboru abc.gif. Tato tabulka je velmi malá (řádově desítky až stovky kilobytů) a její kopie je neustále v paměti. Pro hledání v cache tedy na disk vůbec nechodíte. A věřte tomu, že váš HDD nemá problém přečíst desítky až stovky malých souborů za sekundu, zatímco vaše internetové připojení s tím bude mít dost zásadní problém. Přesněji řečeno, vystavovací doba vašeho HDD je řádově jinde než váš ping.

A co by se v te cachi melo „prohledavat“? Z cache se rovnou bere.

Určitě tu cache neprohledávají, ale používají hashovací tabulku, či něco podobného.

Cache je asociativní tabulka. Ta se neprohledává. Bohužel řada lidí toto neví a cache si představují jako šuplík u stolu, kam házím věci a když potřebuji, tak šuplík prohledám a věci možná najdu. Jenže taková věc by třebas u procesoru byla silně na obtíž. Proto cache vždy obsahují asociativní pole, kde pro zadaný klíč ihned vím, zda to v cache mám (a kde), nebo ne. Hashovací tabulka je jedna z nejčastějších implementací cache – spočítám hash a ten použiji rovnou jako index do pole. Žádné vyhledávání, jdu na jisto. Na hledání není čas.

Závidím Vám 200Gb/s připojení k internetu srovnatelné s rychlostí čtení z pevného disku. Pro běžná připojení v řádech jednotek Mb/s je cache zcela zásadní.
Naopak si myslím, že 250MB je při dnešních velikostech disků a objemu multimediálního obsahu na internetu extrémně málo. Klidně by tam mohli jako výchozí hodnotu nastavit nějaký ten gigabajt.
Já osobně prosurfuji minimálně 1GB za den. Kdybych měl cache jen 250MB, postrádala by smysl, protože by se přepsala během pár hodin.

Je to pochopitelně překlep, má to být MB :-)

… Závidím Vám 200Gb/s připojení k internetu srovnatelné s rychlostí čtení z pevného disku …
zaujimal by ma myslienkovy postup, ktory dal tento vysledok …

Ak to bol preklep a malo tam byt 200 MB/s, tak to je tiez obrovske cislo pre rychlost disk.
Bezne desktopove PC moze dat 30, max 40 MB/s pri citani SUVISLEHO velkeho bloku dat.
Cache s velkostou 250 MB moze znamenat milion malych suborov ⇒ pre HDD s rotujucou platnou a pohyblivou citaciou hlavickou velky vykonnostny problem pri hladani jedneho maleho objektu v cache.

Je to stále dokola. NIC se nehledá. „Jde“ se NAJISTO. A je to téměř okamžitě načtené.

to by mě zajímalo, jak si představujete jít na jisto.
když před Vás někdo položí mísu s tisícem a dvaceti třemi červenými a jednou modrou kuličkou, tak Vy se podíváte, možná hrábnete a „pujdete na jisto“ a vyberete tu modrou, ale zkuste si to naprogramovat. Nechť máte množinu záznamů o requestech, které jsou uloženy v cache, jak najdete ten záznam, který přísluší Vašemu requestu.
hledání v cache (podle Vás zcela na jisto) si představuju tak, že se najde a otevře(nebo použije otevřený) soubor s posloupností záznamů o uložených objektech v cache(vždycky jsem se divil, že k haváriím těchto záznamů dochází tak málo často, jen při scrashích počítačů). Sekvenčně se vyhledá záznam který odpovídá requestu, který se má provést. Zřejmě se ale využívá nějaký sofistikovaný způsob jak ten záznam najít rychleji než porovnávat záznamy jeden po druhém.
V případě, že se záznam našel, podle aktuálního času a vlastnostech objektu uloženého v cache se může odeslat na server dotaz, zda-li existuje novější verze.(Odešle aktuální ETag data uloženého v cache a server vrátí „304 Not Modified“ nebo nová data) a případně se najde soubor s daty.
já tomu asi nerozumím, protože nevím, kde by se v takovéto situaci dalo chodit na jisto.

„Sekvenčně se vyhledá záznam který odpovídá requestu, který se má provést. Zřejmě se ale využívá nějaký sofistikovaný způsob jak ten záznam najít rychleji než porovnávat záznamy jeden po druhém.“

Nikoliv. Najdi si info o hashovací tabulce a algoritmech a případně si ji zkus naprogramovat. Složitost čtení položky je O(1) (konstantní), nic se (lineárně ani logaritmicky) neprohledává.

Do cache se opravdu jen sáhne pro odpovídající záznam.

Pripadne se pouzije vyhledavaci strom. Obvykle b-tree.

Firefox chce stahnout nejakej obrazek treba, koukne do tabulky co ma v pameti, jestli ten soubor nahodou nema v cachi a pokud ano, nacte soubor. K zadnymu prohledavani cache nedochazi… Celej process je rychlejsi nez i jen otevreni spojeni k HTTP serveru…

30 MB/s? To mozna tak notebookove disky… Dnesni nove desktopove disky (7200 otacek, kapacita radove 500 GB a vic) maji pri cteni souvisleho bloku dat rychlost tak 100–130 MB/sec.
Jinak cache v objektech nehleda, prohlizece maji v cache navic i jeden soubor s indexem se zaznamy typu:
„http://www.ro­ot.cz/“ = „soubor12345“
Ten index pak je i v pameti, takze pri pozadavku na danou url proste nactou primo dany soubor. Je to rychlejsi nez to tahat ze site, ledaze by nekdo mel extremne rychlou sit a k tomu hodne pomaly disk.
Navic prohlizece maji i dalsi (obvykle mensi) cache primo v RAM, takze nekdy nemusi ani lezt na disk.

zavidim vam ten disk :)
poslite na prosim vystup
hdparm -tT /dev/sda
u mna je to napriklad: ~36 MB/sec
/dev/sda:
Timing cached reads: 826 MB in 2.00 seconds = 412.79 MB/sec
Timing buffered disk reads: 108 MB in 3.00 seconds = 35.95 MB/sec

cim to muze byt? ja mam podobne hodnoty cache…

Model=SAMSUNG HD400LD
Timing cached reads: 800 MB in 2.00 seconds = 399.22 MB/sec
Timing buffered disk reads: 216 MB in 3.00 seconds = 71.88 MB/sec

Dva roky starý Samsung F1

hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   12032 MB in  2.00 seconds = 6021.64 MB/sec
 Timing buffered disk reads:  282 MB in  3.00 seconds =  93.91 MB/sec

Rok starý Seagate 7200.12

hdparm -tT /dev/sde
/dev/sde:
 Timing cached reads:   11960 MB in  2.00 seconds = 5986.62 MB/sec
 Timing buffered disk reads:  354 MB in  3.01 seconds = 117.68 MB/sec

Běžné levné SSD (Kingston SSDNow V+), Crystal Disk Mark (mám to na Windows, čtení/zápis):

220MB/s  103MB/s

Ani notebookove disky nejsou tak pomalé:
/dev/sda:
Timing cached reads: 5058 MB in 2.00 seconds = 2533.41 MB/sec
Timing buffered disk reads: 264 MB in 3.04 seconds = 86.97 MB/sec

Běžné desktopové disky dají přes 120MB/s sekvenčně a běžné levné SSD 220MB/s.
40MB/s to údaj tak 6 let starý.

Cece prober se, bezny hodne pomaly desktopovy disk dava 100+MB/s, ty nejrychlejsi pri souvislym cteni prelezou 150MB/s, nahodny cteni je pak hodne nad 50MB/s.
Nehlede na to, ze tech milion malych souboru bude dost pravdepodobne v RAM, protoze se uplatni jeste systemova cache.

A jaký je přínos v tom, stahovat jeden obrázek ze Sítě pokaždé znova (při každém kliknutí)? Co z toho budu mít?

„…navýšení tohoto objemu uložených dat na 250MB. Dojde tomu již ve verzi 4.0.“
sakra tak at to navysi rovnou na 500MB, kdyz vi ze „tomu“ ten objem dojde uz u verze 4.0
:)

Opraveno, díky.

Gratulujem vsetkym zastancom, ktorych disk caka len na to, aby im dnesne dynamicke weby mohol natiahnut z ulozenej cache …

Co je dynamické, ať se tahá čerstvé ze sítě, ale co je statické (většina obrázků, css, js a objemu obecně) ať se bere s místního disku. V čem je problém?
BTW: vynalezli užitečnou věc: v HTTP požadavku If-Modified-Since a v odpovědi: 304 Not Modified. Myslím, že to není úplně horká novinka a že to tu bylo už před HTML 5 ;-) :-)

mě by se líbilo, kdyby se taky dalo nastavit, např, že nemám zájem, aby browser cachoval dynamické stránky, ale jen obrázky… např. to odlišit podle mimetypu…

mě by se líbilo, kdyby se taky dalo nastavit, např, že nemám zájem, aby browser cachoval dynamické stránky, ale jen obrázky… např. to odlišit podle mimetypu…

A jaky mime typ maji ty dynamicke stranky?

Hmm, tak to si spis stezuj na tvurce webu, to je totiz jeho prace aby rek, co se nema a co ma uklada do cache.

Najskor sa naucte co je to mimetype weboveho zdroja, resp. dokumentu, …
http://en.wikipedia.org/wiki/MIME_type

… zajímavější informaci, než to, že se mění default hodnota velikosti diskové cache, :-)

+1 :D

Tomu sa vravi marketing … alebo ako uplacat z hovna bic

Konecne se ff alespoň dotáhl na konkurenci. Uz to začínalo byt silené!

No vidíte, já si třeba zrovna na notebooku cache úplně vypnul, protože je mnohem rychlejší to natáhnout z netu (ve škole, tam jsem na noťasu nejčastěji), než to tahat z disku. Navíc mi strašně vadilo, že když jsem kopíroval z/na externí disk, tak se nadalo ani prohlížet internet, jak ten HDD nestíhal. A z netu je to prostě rychlejší.

No, ono to bude spis rukama, protoze i hodne blba flash da 10+MB/s a pristupova doba je v ns ⇒ min o rad lepsi nez latence po lan. U HDD pak plati, ze 50+MB/s da i hodne spatnej notesovej disk a pristupova doba je v nejhorsim pripade stejna jako po lan (radove ms). … jak rikam, nekdo ma volsovy ruce, neumi si to nastavit a tvrdi ze sit je rychlejsi …