⑴ .net 緩存是什麼 放在哪裡 概念模糊了 大俠幫忙
在 ASP.NET 提供的許多特性中，緩存支持我最欣賞的特性，相比 ASP.NET 的所有其他特性，緩存對應用程序的性能具有最大的潛在影響，利用緩存和其他機制，ASP.NET 開發人員可以接受使用開銷很大的控制項（例如，DataGrid）構建站點時的額外開銷，而不必擔心性能會受到太大的影響。為了在應用程序中最大程度地利用緩存，應該考慮在所有程序級別上都實現緩存的方法。
實現
要實現頁面輸出緩存，只要將一條 OutputCache 指令添加到頁面即可。
＜％@ OutputCache Duration="60" VaryByParam="*" ％＞
如同其他頁面指令一樣，該指令應該出現在 ASPX 頁面的頂部，即在任何輸出之前。它支持五個屬性（或參數），其中兩個是必需的。
Duration
必需屬性。頁面應該被緩存的時間，以秒為單位。必須是正整數。
Location
指定應該對輸出進行緩存的位置。如果要指定該參數，則必須是下列選項之一：Any、Client、Downstream、None、Server 或 ServerAndClient。
VaryByParam
必需屬性。Request 中變數的名稱，這些變數名應該產生單獨的緩存條目。"none" 表示沒有變動。"*" 可用於為每個不同的變數數組創建新的緩存條目。變數之間用 ";" 進行分隔。
VaryByHeader
基於指定的標頭中的變動改變緩存條目。
VaryByCustom
允許在 global.asax 中指定自定義變動（例如，"Browser"）。
利用必需的 Duration 和 VaryByParam 選項的組合可以處理大多數情況。例如，如果產品目錄允許用戶基於 categoryID 和頁變數查看目錄頁，可以用參數值為 "categoryID;page" 的 VaryByParam 將產品目錄緩存一段時間（如果產品不是隨時都在改變，一小時還是可以接受的，因此，持續時間是 3600 秒）。這將為每個種類的每個目錄頁創建單獨的緩存條目。每個條目從其第一個請求算起將維持一個小時。
VaryByHeader 和 VaryByCustom 主要用於根據訪問頁面的客戶端對頁面的外觀或內容進行自定義。同一個 URL 可能需要同時為瀏覽器和行動電話客戶端呈現輸出，因此，需要針對不同的客戶端緩存不同的內容版本。或者，頁面有可能已經針對 IE 進行了優化，但需要能針對 Netscape 或 Opera 完全降低優化（而不僅僅是破壞頁面）。後一個例子非常普遍，將提供一個說明如何實現此目標的示例：
示例：VaryByCustom 用於支持瀏覽器自定義
為了使每個瀏覽器都具有單獨的緩存條目，VaryByCustom 的值可以設置為 "browser"。此功能已經內置在緩存模塊中，並且將針對每個瀏覽器名稱和主要版本插入單獨的頁面緩存版本。
＜％@ OutputCache Duration="60" VaryByParam="None" VaryByCustom="browser" ％＞
片段緩存，用戶控制項輸出緩存
緩存整個頁面通常並不可行，因為頁面的某些部分是針對用戶定製的。不過，頁面的其他部分是整個應用程序共有的。這些部分最適合使用片段緩存和用戶控制項進行緩存。菜單和其他布局元素，尤其是那些從數據源動態生成的元素，也應該用這種方法進行緩存。如果需要，可以將緩存的控制項配置為基於對其控制項（或其他屬性）的更改或由頁面級輸出緩存支持的任何其他變動進行改變。使用同一組控制項的幾百個頁面還可以共享那些控制項的緩存條目，而不是為每個頁面保留單獨的緩存版本。
實現
片段緩存使用的語法與頁面級輸出緩存一樣，但其應用於用戶控制項（.ascx 文件）而不是 Web 窗體（.aspx 文件）。除了 Location 屬性，對於 OutputCache 在 Web 窗體上支持的所有屬性，用戶控制項也同樣支持。用戶控制項還支持名為 VaryByControl 的 OutputCache 屬性，該屬性將根據用戶控制項（通常是頁面上的控制項，例如，DropDownList）的成員的值改變該控制項的緩存。如果指定了 VaryByControl，可以省略 VaryByParam。最後，在默認情況下，對每個頁面上的每個用戶控制項都單獨進行緩存。不過，如果一個用戶控制項不隨應用程序中的頁面改變，並且在所有頁面都使用相同的名稱，則可以應用 Shared="true" 參數，該參數將使用戶控制項的緩存版本供所有引用該控制項的頁面使用。
示例
＜％@ OutputCache Duration="60" VaryByParam="*" ％＞
該示例將緩存用戶控制項 60 秒，並且將針對查詢字元串的每個變動、針對此控制項所在的每個頁面創建單獨的緩存條目。
＜％@ OutputCache Duration="60" VaryByParam="none" VaryByControl="CategoryDropDownList" ％＞
該示例將緩存用戶控制項 60 秒，並且將針對 CategoryDropDownList 控制項的每個不同的值、針對此控制項所在的每個頁面創建單獨的緩存條目。
＜％@ OutputCache Duration="60" VaryByParam="none" VaryByCustom="browser" Shared="true ％＞
最後，該示例將緩存用戶控制項 60 秒，並且將針對每個瀏覽器名稱和主要版本創建一個緩存條目。然後，每個瀏覽器的緩存條目將由引用此用戶控制項的所有頁面共享（只要所有頁面都用相同的 ID 引用該控制項即可）。
頁面級和用戶控制項級輸出緩存的確是一種可以迅速而簡便地提高站點性能的方法，但是在 ASP.NET 中，緩存的真正靈活性和強大功能是通過 Cache 對象提供的。使用 Cache 對象，您可以存儲任何可序列化的數據對象，基於一個或多個依賴項的組合來控制緩存條目到期的方式。這些依賴項可以包括自從項被緩存後經過的時間、自從項上次被訪問後經過的時間、對文件和/或文件夾的更改以及對其他緩存項的更改，在略作處理後還可以包括對資料庫中特定表的更改。
在 Cache 中存儲數據
在 Cache 中存儲數據的最簡單的方法就是使用一個鍵為其賦值，就像 HashTable 或 Dictionary 對象一樣：
Cache["key"] = "value";
這種做法將在緩存中存儲項，同時不帶任何依賴項，因此它不會到期，除非緩存引擎為了給其他緩存數據提供空間而將其刪除。要包括特定的緩存依賴項，可使用 Add() 或 Insert() 方法。其中每個方法都有幾個重載。Add() 和 Insert() 之間的唯一區別是，Add() 返回對已緩存對象的引用，而 Insert() 沒有返回值（在 C# 中為空，在 VB 中為 Sub）。
示例
Cache.Insert("key", myXMLFileData, new System.Web.Caching.CacheDependency(Server.MapPath("users.xml")));
該示例可將文件中的 xml 數據插入緩存，無需在以後請求時從文件讀取。 CacheDependency 的作用是確保緩存在文件更改後立即到期，以便可以從文件中提取最新數據，重新進行緩存。如果緩存的數據來自若干個文件，還可以指定一個文件名的數組。
Cache.Insert("dependentkey", myDependentData, new System.Web.Caching.CacheDependency(new string[] {}, new string[]
{"key"}));
該示例可插入鍵值為 "key" 的第二個數據塊（取決於是否存在第一個數據塊）。如果緩存中不存在名為 "key" 的鍵，或者如果與該鍵相關聯的項已到期或被更新，則 "dependentkey" 的緩存條目將到期。
Cache.Insert("key", myTimeSensitiveData, null, DateTime.Now.AddMinutes(1), TimeSpan.Zero);
絕對到期：此示例將對受時間影響的數據緩存一分鍾，一分鍾過後，緩存將到期。注意，絕對到期和滑動到期（見下文）不能一起使用。
Cache.Insert("key", myFrequentlyAccessedData, null,
System.Web.Caching.Cache.NoAbsoluteExpiration,
TimeSpan.FromMinutes(1));
滑動到期：此示例將緩存一些頻繁使用的數據。數據將在緩存中一直保留下去，除非數據未被引用的時間達到了一分鍾。注意，滑動到期和絕對到期不能一起使用。
更多選項
除了上面提到的依賴項，我們還可以指定項的優先順序（依次為 low、high、NotRemovable，它們是在 System.Web.Caching.CacheItemPriority 枚舉中定義的）以及當緩存中的項到期時調用的 CacheItemRemovedCallback 函數。大多數時候，默認的優先順序已經足夠了 — 緩存引擎可以正常完成任務並處理緩存的內存管理。CacheItemRemovedCallback 選項考慮到一些很有趣的可能性，但實際上它很少使用。不過，為了說明該方法，我將提供它的一個使用示例：
CacheItemRemovedCallback 示例
System.Web.Caching.CacheItemRemovedCallback callback = new System.Web.Caching.CacheItemRemovedCallback (OnRemove);
Cache.Insert("key",myFile,null,
System.Web.Caching.Cache.NoAbsoluteExpiration,
TimeSpan.Zero,
System.Web.Caching.CacheItemPriority.Default, callback);
. . .
public static void OnRemove(string key,
object cacheItem,
System.Web.Caching.CacheItemRemovedReason reason)
{
AppendLog("The cached value with key " + key +
" was removed from the cache. Reason: " +
reason.ToString());
}
該示例將使用 AppendLog() 方法（這里不討論該方法，請參閱 Writing Entries to Event Logs）中定義的任何邏輯來記錄緩存中的數據到期的原因。通過在從緩存中刪除項時記錄這些項並記錄刪除的原因，您可以確定是否在有效地使用緩存或者您是否可能需要增加伺服器上的內存。注意，callback 是一個靜態（在 VB 中為 Shared）方法，建議使用該方法的原因是，如果不使用它，保存回調函數的類的實例將保留在內存中，以支持回調（對 static/Shared 方法則沒有必要）。
該特性有一個潛在的用處 — 在後台刷新緩存的數據，這樣用戶永遠都不必等待數據被填充，但數據始終保持相對較新的狀態。但實際上，此特性並不適用於當前版本的緩存 API，因為在從緩存中刪除緩存的項之前，不觸發或不完成回調。因此，用戶將頻繁地發出嘗試訪問緩存值的請求，然後發現緩存值為空，不得不等待緩存值的重新填充。我希望在未來的 ASP.NET 版本中看到一個附加的回調，可以稱為 ，如果定義了該回調，則必須在刪除緩存項之前完成執行。
緩存數據引用模式
每當我們嘗試訪問緩存中的數據時，都應該考慮到一種情況，那就是數據可能已經不在緩存中了。因此，下面的模式應該普遍適用於您對緩存的數據的訪問。在這種情況下，我們假定已緩存的數據是一個數據表。
public DataTable GetCustomers(bool BypassCache)
{
string cacheKey = "CustomersDataTable";
object cacheItem = Cache[cacheKey] as DataTable;
if((BypassCache) (cacheItem == null))
{
cacheItem = GetCustomersFromDataSource();
Cache.Insert(cacheKey, cacheItem, null,
DateTime.Now.AddSeconds(GetCacheSecondsFromConfig(cacheKey),
TimeSpan.Zero);
}
return (DataTable)cacheItem;
}
關於此模式，有以下幾點需要注意：
某些值（例如，cacheKey、cacheItem 和緩存持續時間）是一次定義的，並且只定義一次。
可以根據需要跳過緩存 — 例如，當注冊一個新客戶並重定向到客戶列表後，最好的做法可能就是跳過緩存，用最新數據重新填充緩存，該數據包括新插入的客戶。
緩存只能訪問一次。這種做法可以提高性能，並確保不會發生 NullReferenceExceptions，因為該項在第一次被檢查時是存在的，但第二次檢查之前就已經到期了。
該模式使用強類型檢查。C# 中的 "as" 運算符嘗試將對象轉換為類型，如果失敗或該對象為空，則只返回 null（空）。
持續時間存儲在配置文件中。在理想的情況下，所有的緩存依賴項（無論是基於文件的，或是基於時間的，還是其他類型的依賴項）都應該存儲在配置文件中，這樣就可以進行更改並輕松地測量性能。我還建議您指定默認緩存持續時間，而且，如果沒有為所使用的 cacheKey 指定持續時間，就讓 GetCacheSecondsFromConfig() 方法使用該默認持續時間。
相關的代碼示例是一個 helper 類，它將處理上述所有情況，但允許通過一行或兩行代碼訪問緩存的數據。請下載 CacheDemos.msi。
小結
緩存可以使應用程序的性能得到很大的提高，因此在設計應用程序以及對應用程序進行性能測試時應該予以考慮。應用程序總會或多或少地受益於緩存，當然有些應用程序比其他應用程序更適合使用緩存。對 ASP.NET 提供的緩存選項的深刻理解是任何 ASP.NET 開發人員應該掌握的重要技巧。
盡早緩存；經常緩存
您應該在應用程序的每一層都實現緩存。向數據層、業務邏輯層、UI 或輸出層添加緩存支持。內存現在非常便宜 — 因此，通過以智能的方式在整個應用程序中實現緩存，可以獲得很大的性能提高。
緩存可以掩蓋許多過失
緩存是一種無需大量時間和分析就可以獲得"足夠良好的"性能的方法。這里再次強調，內存現在非常便宜，因此，如果您能通過將輸出緩存 30 秒，而不是花上一整天甚至一周的時間嘗試優化代碼或資料庫就可以獲得所需的性能，您肯定會選擇緩存解決方案（假設可以接受 30 秒的舊數據）。緩存正是那些利用 20％ 付出獲得 80％ 回報的特性之一，因此，要提高性能，應該首先想到緩存。不過，如果設計很糟糕，最終卻有可能帶來不良的後果，因此，您當然也應該盡量正確地設計應用程序。但如果您只是需要立即獲得足夠高的性能，緩存就是您的最佳選擇，您可以在以後有時間的時候再盡快重新設計應用程序。
頁面級輸出緩存
作為最簡單的緩存形式，輸出緩存只是在內存中保留為響應請求而發送的 HTML 的副本。其後再有請求時將提供緩存的輸出，直到緩存到期，這樣，性能有可能得到很大的提高（取決於需要多少開銷來創建原始頁面輸出 - 發送緩存的輸出總是很快，並且比較穩定）。
⑵ 清除WebSphere中緩存
可能是部署在WebSphere裡面的項目還沒有去刪除吧？，。。
⑶ 系列分享之瀏覽器、本地DNS緩存篇
我們在使用瀏覽器訪問互聯網資源時,想獲取指定的服務和信息。首先就要了解瀏覽器是如何定位到我們的站點的。輸入一個域名(如:www.jd.com)瀏覽器會首先從自身的緩存中查詢是否有歷史域名對應的IP並且有效，如果有就使用該緩存通過IP直接訪問到指定的站點。如果沒有則查詢本地的Host緩存，如果有就使用本地的緩存直接訪問站點，沒有則向本地DNS伺服器發起請求查詢，如果本地DNS服務也沒有找到，則向公網DNS服務發起查詢請求獲取對應的有效IP，並返回緩存到瀏覽器和本地緩存中，供後續請求使用。
DNS記錄會有一個ttl值(time to live)，單位是秒，意思是這個記錄最大有效期是多少。操作系統緩存會參考ttl值，但是不完全等於ttl值，而瀏覽器DNS緩存的時間跟ttl值無關，每種瀏覽器都使用一個固定值。
DNS查詢請求類型:
1、權威答復：權威答復是返回給客戶的正向答復，並且設置了DNS消息中的權威位。此答復代表從具有權威的DNS伺服器處發出。
2、正向答復：正向答復包含了匹配客戶端解析請求的資源記錄。
3、參考答復：參考答復只在DNS伺服器工作在迭代模式下使用，包含了其他有助於客戶端解析請求的信息。例如，當DNS伺服器不能為客戶端發起的解析請求找到某個匹配值時，則向DNS客戶端發送參考回復，告訴它有助於解析請求的信息。
4、否定答復：否定答復指出權威伺服器在解析客戶端的請求時可能遇到了以下兩種情況之一：
權威DNS伺服器報告客戶端查詢的名字不存在；
權威DNS伺服器報告存在對應的名字,但是不存在指定類型的資源記錄。
DNS伺服器解析返回IP分配策略與客戶端對域名IP選擇策略,無論正向答復還是否定答復，DNS客戶端都將結果保存在自己的本地緩存中
瀏覽器緩存：
瀏覽器在獲取網站域名的實際IP地址後會對其IP進行緩存，減少網路請求的損耗。每種瀏覽器都有一個固定的DNS緩存時間。
參考瀏覽器DNS緩存時間：
本地緩存：
每種操作系統都有自己的DNS緩存時間控制。
1、Windows DNS默認值是MaxCacheTTL，它的默認值是86400s，也就是一天。
2、MacOS遵循DNS協議中的TTL,根據各種網路協議不同對不同的域名採用不同的緩存時間策略。在IPv4包頭中TTL是一個8 bit欄位，它位於IPv4包的第9個位元組。
參考本地DNS緩存時間：
在命令行執行nslookup指令可以看到一個域名對應的IP地址，並且可以幫助我們判斷是否有DNS劫持。隨便解析一個網站，比如
www.jd.com 應該返回的是正常的地址
然後再解析一個不存在的網站，比如123123.aaaa.com.cn如果返回的結果是
DNS request timed out.
timeout was 2 seconds.
那麼證明你的DNS沒有被劫持。
如果返回的結果是一個IP地址，比如說網通的返回地址是230.xxx.xxx.xxx，那麼證明你的DNS被劫持了。
通過了解瀏覽器、本地緩存可以幫助我們更好的為用戶服務。
1、大型的互聯網公司都有IP流量監控，當發生網路故障或劫持時可以第一時間發現。
2、頁面是我們與用戶面對面溝通的渠道和方式，當我們的網頁和服務呈現在用戶面前時，我們要了解我們提供的服務是如何影響到用戶的體驗的，比如我們前端頁面的JS、CSS等文件的動態版本號處理方式結合緩存是如何變化的，每次發版會對什麼樣的用戶有影響，都需要嚴謹。
3、機房內部的各個應用程序服務，比如Zookeeper、Redis、RPC、DB在DNS緩存變化時，可能引起的網路抖動，是否會對用戶請求造成影響，也是我們必須要注意的問題。
⑷ 系統臨時文件、IE緩存文件和windows預讀文件都是什麼
你好朋友；
系統臨時文件；就是你在運行程序或操作系統在運行過程中產生的一種文件；
擴展名為.tmp有一些還是.temp的；臨時文件屬於垃圾文件的一種；
ie緩存文件；
ie緩存文件實際上就是internet臨時文件；這種文件是你用瀏覽器上網時候產生的；
瀏覽器在訪問網站的過程中；是先把網站伺服器硬碟中的內容【包括視頻；音樂；圖片；vbs腳本；js腳本】這些東西先以緩存的方式儲存到你電腦中的internet臨時文件夾內；然後再在屏幕上顯示和播放出來的；
windows的預讀文件； Win XP用來放預讀文件的文件夾預讀是微軟採用的一種加速程序進程啟動速度的技術；主要原理是在開機載入操作系統的時候讀取常用程序的主要內容以備該程序啟動時耗費大量時間來讀取本身的數據。
目錄
數據預讀機制
常見問題
解決辦法
局部碎片整理
開啟預存取
defrag的參數
經驗談
MS網站上對prefetch的解釋
數據預讀機制
微軟採用的一種全新系統後台數據預讀機制；它可以提高系統性能；加快Windows XP/2003的啟動速度；經過預讀的程序全部存放在系統所在文件夾下的prefetcher目錄中（圖1）；文件名格式類似於下面這個樣子；FOXMAIL.EXE-2B721FDE.pf（這是Foxmail的預讀文件）；Windows XP/2003雖然採用了預讀取機制；但是默認設置下比較保守；我們可以自己來定義程序的預讀取方式；大幅度提高系統的性能；
常見問題；
在使用Windows XP較長時間後；我們會發現系統運行速度明顯慢了下來；用多優化軟體；卸載已經安裝的軟體都解決不了問題；究竟為什麼呢？原來罪魁禍首就是預讀設置；在「Windows＼Prefetch」文件夾面有很多個以PF為擴展名的文件；這就是預讀文件；如果將裡面的文件清空以後；你就會發現系統運行速度又恢復正常了；看來；預讀設置可以提高系統速度；但是使用一段時間後；預讀文件夾里的文件又會變得很多了；導致系統搜索花費的時間變得很長；而且有些應用程序會產生死鏈接文件；進而加重了系統搜索的負擔；
解決辦法；
因此；我們應該定期刪除這些預讀文件；用以提高開機速度；當然；Windows XP重新設置預讀對象是允許的；具體方法是；打開注冊表編輯器；依次展開HKEY_LOCAL_MACHINE＼SYSTEM＼ CurrentControlSet＼Control＼Session Manager＼Memory Management＼PrefetchParameters分支；在右側窗口中雙擊「EnablePrefetcher」；在打開的「DWORD」值編輯窗口中；可以對Windows XP進行預讀設置；將該值設置為「0」；即為取消預讀功能；設置為「1」；系統將只預讀應用程序；設置為「2」；系統將只預讀Windows系統文件；設置為 「3」；系統將預讀Windows系統文件和應用程序；一般我們將該值設置為「2」即可；當然；如果你的計算機配置很高；如使用PIII 800MHz CPU以上的建議將數值數據更改為4或5；也可以保留數值數據為默認值即3；這樣可以加快系統運行速度；prefetch；預存取；這在vista用戶可能知道的多些；其實xp下就有這一技術了；只是官方少有這方面介紹；更別提技術文檔了；這是xp一個隱藏的特性；用處是在xp登錄進度條出現時；就把c:\windows\prefetch目錄下的*.pf文件信息預先裝載到內存中；以便於提高系統性能；這些*.pf文件是系統和應用程序啟動時留下的預存取文件；描述了系統和應用程序每次啟動時裝載模塊的信息和順序；並且其命名方式中包含一個描述其完整路徑的十六進制值；另外；prefetch目錄中還有一個重要文件；就是layout.ini這個磁碟布局初始化文件；它記錄了所有預存取程序及文件的載入信息和順序（按優先順序排列）；這也為這些程序文件的磁碟分配提供了最優化方案的依據；
局部碎片整理；
說到這；不得不提一下「局部碎片整理」；按照官方所說；xp每隔3天就會自動進行一次局部碎片整理；我發現這個整理動作是分步實施的；而且是在系統空閑時才會運行；這多虧了剛裝上的SSM截獲了defrag的這個動作信息；連命令行參數都一並截獲；這個重點留待稍後再說；（其實系統在啟動時也可以進行局部碎片整理；使得啟動時需要的文件能夠被整理到相鄰位置；這個功能可以在注冊表中開啟；HKLM\SOFTWARE\Microsoft\Dfrg\BootOptimizeFunetion下enable鍵由默認的N改為Y即可）用Filemon跟蹤發現；系統進行局部碎片整理時；先讀取layout.ini文件；然後調用defrag針對layout.ini中涉及的文件進行整理；然後把轉移信息再寫入到layout.ini中；這個自動整理不同於server2003系統的自動碎片整理功能（Auto Defragmenter）；
開啟預存取；
至於是否開啟預存取；有不少爭論；但是我堅決認為應該開啟；否則系統速度會變得更慢；HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters目錄下；EnablePrefeteher子鍵的值決定以何種方式開啟prefetch；0取消；1隻預存取應用程序；2隻預存取windows系統文件；3同時存取系統和應用程序文件；xp默認情況下是3；以上這些prefetch相關功能依賴於task schele計劃任務這項服務；defrag的參數；
現在該說那個重點了；系統自動調用的defrag的參數是什麼？是-p -s和-b。-p後面跟著一個常量；例如5E4；-s後也跟一個常量；比如000018A4；-b後跟著盤符C：；那麼這個命令行的例子就是；defrag.exe -p 5E4 -s 000018A4 -b C: 了；-b這個參數網上一直有傳言；說是defrag的隱藏參數；但是官方不給出澄清；我也不知道是否真的存在；這回算是證實了；-b C:就是對預存取的文件進行局部整理；並且每次僅針對一個pf文件相關程序文件進行整理；-p和-s應該就是用來選擇哪一個pf的；但具體那兩個常量和被選pf文件有什麼聯系；還有待進一步分析；平時如果想對系統和應用程序文件進行一次優化碎片整理；可以在命令行中敲入defrag.exe C: -b；這樣會對所有prefetch文件進行整理；完成後你會覺得系統的速度有一定提升；
段經驗談
經驗之談；如果不小心刪除了prefetch目錄下的文件；尤其是layout.ini文件；如何重建？敲入rundll32.exe advapi32.dll,ProcessIdleTasks命令；然後重啟三次系統；就可以重建layout.ini文件；為什麼是三次；我也不知道；大概和每隔三天整理一次有關系吧；windows xp開機有一個進度條；會一遍一遍的跑；不少人認為只跑兩圈就進去的就是開機速度快；網上出現過一種優化方式；修改注冊表將所謂的「開機預讀取」設置為「不預讀」；則可以大大減少進度條「跑」的次數；但是這種「優化方法」出來不久；便有更多的文章指出這是「謬誤」；還舉出相當多的事例；或是試驗；說明不預讀並不能減少開機時間；大多的理由是進度條消失後的「黑屏時間」增加；因為一直用的休眠；所以我一直也沒怎麼在意；前兩天和別人談到這個問題；我便好好研究一番；結論是；其實關於這個問題；所謂設置為「不預讀」的優化方法也並非謬誤；而這個所謂的預讀也並非沒有用處；否則MS怎麼也不會花人力物力弄這么個浪費開機時間的東西；先說說什麼是所謂的「預讀取」；預讀取分兩種；一種是「系統文件預讀」；一種是「應用程序預讀」；具體的不去討論；現在只討論預讀取對速度的影響；我們都有經驗；當第一次打開word的時候會等待比較長的時間；硬碟燈不停的在亮；但是關閉再次打開；word啟動速度就快得多了；這個其實就是windows的預讀取做的優化；windows預讀取發現你帶開了一個他的預讀取資料庫沒有的應用程序時；他就會將這個應用程序中某些信息在內存中留下一個映象；下次打開這個程序就不用再去硬碟上找文件；能大大加塊程序啟動速度；問題來了；內存中的映象重新啟動之後就會消失；下次開機啟動程序依然很慢；怎麼辦呢？這就需要「開機預讀取」功能；Windows會把使用頻率較高的一些應用程序的信息記錄下來；每次開機時；就完成一次對程序的預讀取；從而大大加快應用程序的啟動速度；你大概已經猜到；那個「進度條」一遍一遍的跑的時候，windows就在進行開機預讀取的工作；因此；如果直接取消掉注冊表中的「預讀取功能」是一定會大大降低應用程序的啟動速度的；當然開機速度會有一定的增加；不過這是得不償失；因為沒有了那一段必要的「系統文件預讀取」；在進度條消失之後系統會從硬碟上去尋找大量的系統文件；反而影響啟動速度；而且應用程序的啟動速度也是一定會大大減慢的；其實比較好的優化辦法是這樣；找到「開機預讀取」的信息；手動把不是很常用；不需要預讀取的應用程序刪除；盡量減少開機預讀取的應用程序的數量；由此來加快啟動速度！；位置在x:\windows\prefetch下面；命名是 exe文件名-16進制hash.exe；有一些實測數據；一台裝了許多應用軟體的電腦；不作處理；開機29s,取消預讀取；開機32s；刪除prefetch文件夾下面大部分文件後；開機23s,有比較明顯的開機速度提升；不過第一次運行應用程序的時候速度的確有所下降；並且prefetch文件夾下文件會自動生成；越來越多；其中最「有效」的一個文件是NTOSBOOT-B00DFAAD.pf；它可以大大提高Windows的啟動速度；如果只求啟動速度的話；可以只保留這個文件和Layout.ini；然後將Task Scheler服務設為手動；當然；要想真正看到預讀效果；必須保證開機後內存佔用小於物理內存量；（比如：開機後從任務管理器看出內存佔用是480MB；而你的物理內存是256MB的；那麼就幾乎看不到預讀的效果；
MS網站上對prefetch的解釋；
Prefetch；All versions of Windows except real-mode Windows 3x are demand-paged operating systems, where file data and code is faulted into memory from disk as an application attempts to access it. Data and code is faulted in page-granular chunks where a page's size is dictated by the CPU's memory management hardware. A page is 4KB on the x86. Prefetching is the process of bringing data and code pages into memory from disk before it's demanded. In order to know what it should prefetch, the Windows XP Cache Manager monitors the page faults, both those that require that data be read from disk (hard faults) and those that simply require that data already in memory be added to a process's working set (soft faults), that occur ring the boot process and application startup. By default it traces through the first two minutes of the boot process, 60 seconds following the time when all Win32 services have finished initializing, or 30 seconds following the start of the user's shell (typically Microsoft Internet Explorer), whichever of these three events occurs first. The Cache Manager also monitors the first 10 seconds of application startup. After collecting a trace that's organized into faults taken on the NTFS Master File Table (MFT) metadata file (if the application accesses files or directories on NTFS volumes), the files referenced, and the directories referenced, it notifies the prefetch component of the Task Scheler by signaling a named event object. The Task Scheler then performs a call to the internal NtQuerySystemInformation system call requesting the trace data. After performing post-processing on the trace data, the Task Scheler writes it out to a file in the \Windows\Prefetch folder. The file's name is the name of the application to which the trace applies followed by a dash and the hexadecimal representation of a hash of the file's path. The file has a .pf extension, so an example would be NOTEPAD.EXE-AF43252301.PF. An exception to the file name rule is the file that stores the boot's trace, which is always named NTOSBOOT-B00DFAAD.PF (a convolution of the hexadecimal-compatible word BAADF00D, which programmers often use to represent uninitialized data). Only after the Cache Manager has finished the boot trace (the time of which was defined earlier) does it collect page fault information for specific applications. 這個似乎是最影響啟動速度的文件，也就是所謂的「系統文件預讀取」吧 When the system boots or an application starts, the Cache Manager is called to give it an opportunity to perform prefetching. The Cache Manager looks in the prefetch directory to see if a trace file exists for the prefetch scenario in question. If it does, the Cache Manager calls NTFS to prefetch any MFT metadata file references, reads in the contents of each of the directories referenced, and finally opens each file referenced. It then calls the Memory Manager to read in any data and code specified in the trace that's not already in memory. The Memory Manager initiates all of the reads asynchronously and then waits for them to complete before letting an application's startup continue. How does this scheme provide a performance benefit? The answer lies in the fact that ring typical system boot or application startup, the order of faults is such that some pages are brought in from one part of a file, then from another part of the same file, then pages are read from a different file, then perhaps from a directory, and so on. This jumping around results in moving the heads around on the disk. Microsoft has learned through analysis that this slows boot and application startup times. By prefetching data from a file or directory all at once before accessing another one, this scattered seeking for data on the disk is greatly reced or eliminated, thus improving the overall time for system and application startup. Figure 1 Prefetch Directory To minimize seeking even further, every three days or so, ring system idle periods, the Task Scheler organizes a list of files and directories in the order that they are referenced ring a boot or application start, and stores the list in a file named \Windows\Prefech\Layout.ini. Figure 1 shows the contents of a prefetch directory, highlighting the layout file. Then it launches the system defragmenter with a command-line option that tells the defragmenter to defragment based on the contents of the file instead of performing a full defrag. The defragmenter finds a contiguous area on each volume large enough to hold all the listed files and directories that reside on that volume and then moves them in their entirety into that area so that they are stored one after the other. Thus, future prefetch operations will even be more efficient because all the data to be read in is now stored physically on the disk in the order it will be read. Since the number of files defragmented for prefetching is usually only in the hundreds, this defragmentation is much faster than full defragmentations.