【正文】 時間相關(guān)性或地方的職權(quán)范圍。 一般的，caching成功有2個原因： 不一致的請求。 清楚的，cache越大，越容易避免丟失。另一方面，算法必須選擇驅(qū)逐一個項目來空出空間來存放那個丟失的項目，或者不加入那個丟失的項目。另一方面，這種情況叫做 丟失或者失敗。 Caching術(shù)語就像下面：cache是內(nèi)存用來儲存同等大小的元素。在一個網(wǎng)絡(luò)環(huán)境中，也是分層的。 在大多數(shù)的計算機系統(tǒng)里面，內(nèi)存是分等級的，意思是，存在2級或更多級的內(nèi)存，表現(xiàn)出不同的空間和速度。一般的，達到避免可以用維護一個發(fā)現(xiàn)URLs的集合。 任何網(wǎng)絡(luò)爬蟲必須維護一個集合，裝那些需要被下載的URLs。沒有責任通過TCP傳送這個URL給網(wǎng)絡(luò)爬蟲，有責任把這些URLs綁在一起減少TCP開銷。Mercator使用了一個獨立的集合，通信網(wǎng)絡(luò)爬蟲進程。這些不同的進程通過文件系統(tǒng)通信。 最初的google 爬蟲，實現(xiàn)不同的爬蟲組件通過不同的進程。 網(wǎng)絡(luò)爬蟲用網(wǎng)絡(luò)存檔雇員多個爬行進程，每個一次性完成一個徹底的爬行對于64個hosts 。 網(wǎng)絡(luò)爬蟲的出現(xiàn)幾乎和網(wǎng)絡(luò)同期，而且有很多的文獻描述了網(wǎng)絡(luò)爬蟲。第6部分是我們推薦的實際算法和數(shù)據(jù)結(jié)構(gòu)關(guān)于URLcache。第4部分我們實現(xiàn)這些算法，在實驗機制中。 這個論文像這樣組織的：第2部分討論在文學著作中幾種不同的爬行解決方案和什么樣的cache最適合他們。我們考慮所有實際的算法：隨機置換，靜態(tài)cache，LRU，和CLOCK，和理論極限：透視cache和極大的cache。 一個非常重要的方法加速這個檢測就是用cache（高速緩存），這個是把見過的URLs存入主內(nèi)存中的一個（動態(tài)）子集中。因此，步驟（a）必須執(zhí)行大約每秒1000次，成員檢測的步驟（c）必須每秒執(zhí)行超過10000次，并有非常大的數(shù)據(jù)儲存到主內(nèi)存中。如果我們認為頁面改變?nèi)种换蛘吒?，那么有大約7%的頁面每周會變。網(wǎng)絡(luò)的頁面改變很頻繁?，F(xiàn)在，Google需要索引超過30億的網(wǎng)頁。2種標準的策略是深度優(yōu)先算法和廣度優(yōu)先算法他們?nèi)菀妆粚崿F(xiàn)所以在很多入門的算法課中都有教。（估計有超過20%）如果把網(wǎng)頁看作圖中的節(jié)點，把超鏈接看作定向的移動在這些節(jié)點之間，那么網(wǎng)絡(luò)爬蟲就變成了一個進程就像數(shù)學中的圖的遍歷一樣?；镜乃惴ㄊ牵篎etch a pageParse it to extract all linked URLsFor all the URLs not seen before，repeat（a）(c)網(wǎng)絡(luò)怕從一般開始于一些 種子URLs。因此，一個強大的搜索引擎技術(shù)有巨大的實際利益，在這個論文中，我們集中于一方面的搜索技術(shù)，也就是搜集網(wǎng)頁的過程，最終組成一個搜索引擎的文集。我們推測這個臨界點是固有的并且冒昧的解釋一下這個現(xiàn)象。 我們的主要的結(jié)論是 cache是非常高效的在我們的機制里，一個有大約50000個入口的cache可以完成80%的速率。我們考慮所有實際的算法：隨機置換，靜態(tài)cache，LRU，和CLOCK，和理論極限：透視cache和極大的cache。 一個非常重要的方法加速這個檢測就是用cache（高速緩存），這個是把見過的URLs存入主內(nèi)存中的一個（動態(tài)）子集中。實際上，光是這兩個要素就意味著如果要進行及時地，完全地爬行網(wǎng)絡(luò)，步驟（a）必須每秒鐘執(zhí)行大約1000次，因此，成員檢測（c）必須每秒鐘執(zhí)行超過10000次，并有非常大的數(shù)據(jù)儲存到主內(nèi)存中。 the different crawler ponents are implemented as different processes. A “crawling application” maintains the set of URLs to be downloaded, and schedules the order in which to download them. It sends download requests to a “crawl manager”, which forwards them to a pool of “downloader” processes. The downloader processes fetch the pages and save them to an NFSmounted file system. The crawling application reads those saved pages, extracts any links contained within them, and adds them to the set of URLs to be downloaded. Any web crawler must maintain a collection of URLs that are to be downloaded. Moreover, since it would be unacceptable to download the same URL over and over, it must have a way to avoid adding URLs to the collection more than once. Typically, avoidance is achieved by maintaining a set of discovered URLs, covering the URLs in the frontier as well as those that have already been downloaded. If this set is too large to fit in memory (which it often is, given that there are billions of valid URLs), it is stored on disk and caching popular URLs in memory is a win: Caching allows the crawler to discard a large fraction of the URLs without having to consult the diskbased set. Many of the distributed web crawlers described above, namely Mercator [29], WebFountain [16], UbiCrawler[4], and Cho and Molina’s crawler [13], are prised of cooperating crawling processes, each of which downloads web pages, extracts their links, and sends these links to the peer crawling process responsible for it. However, there is no need to send a URL to a peer crawling process more than once. Maintaining a cache of URLs and consulting that cache before sending a URL to a peer crawler goes a long way toward reducing transmissions to peer crawlers, as we show in the remainder of this paper.3. CACHINGIn most puter systems, memory is hierarchical, that is, there exist two or more levels of memor