⑴ .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.