頁面部分緩存

A. asp.net頁面緩存

1.可以這么說 但是.net是存到內存 反正是在本地
2.是的 .net默認的緩存好像時間接近半小時 沒注意過 一般我會自己設成 15分鍾
3.正確
4.不會相差很遠 但是.net第一次載入偏慢 但是不可否認 肯定是 htm之類的純靜態頁面速度會比較快
---------------------------------------
1.不知道你的站點地圖具體是什麼 如果是靜態的鏈接 不涉及到邏輯 許可權等 完全可以用靜態文件的
2.伺服器的配置一般教高 所以 執行.net肯定是比本地快的 至於速度 還要取決於client的網路的速度

B. 母版頁如何頁面部分緩存

把treeView做到一個用戶控制項里，然後設置用戶控制項的緩存，

或者直接把treeView放到Cache里去，

C. ASP.NET幾種清除頁面緩存的方法

在asp.net中使用模式dialog時，你會發現每次打開的頁面都是相同的內容，頁面內容並沒有刷新，這是緩存的原因造成的，
解決方法如下：
第一種是ASP.NET清除頁面緩存
Response.Buffer = true;
Response.ExpiresAbsolute = System.DateTime.Now.AddSeconds(-1);
Response.Expires = 0;
Response.CacheControl = "no-cache";
Response.AddHeader("Pragma", "No-Cache");
第二種是HTML方法<HEAD<META HTTP-EQUIV="Pragma" CONTENT="no-cache"
<META HTTP-EQUIV="Cache-Control" CONTENT="no-cache"
<META HTTP-EQUIV="Expires" CONTENT="0"</HEAD第三種是重新調用原頁面的時候在給頁面傳一個參數: href="****.ASPX?random()"
最後一種是在在頁面中禁用緩存
在web開發中合理使用緩存可以有效的提高網站的性能，但是在某些場合下因為緩存的存在會帶來很多的問題。
例如：因為緩存的存在會造成重復提交數據的問題，驗證碼圖片不能正確顯示的問題
，等等。這個時候我們就要禁用頁面緩存的功能。
我們常用的做法是發送一個no-cache的指令，但是實際使用過程中我們發現，這個指令對IE是有效的，但是對Firefox卻沒有效，這是因為，使用該指令Firefox不緩存HTTPS pages 但是還是會緩存HTTP pages ，這是Firefox的一個BUG，解決的辦法很簡單，就是使用no-store代替no-cache，同時發送no-store和no-cache指令
ASP.net中的處理方法，在不需要緩存的頁面中添加如下代碼

D. 為什麼瀏覽器打開部分網頁總是在緩存，打不開

額
是緩沖，不是緩存，緩存是存在的臨時記錄文件，能很快打開的就是那些已經下載下來的網頁，叫做緩存。可能有兩方面，
1
是你網速的問題，2就是你安的插件很多，把沒用的卸載了，我覺得IE8或者9就已經不錯了沒必要第三方瀏覽器

E. 怎麼清理網頁緩存

以網路瀏覽器為例：

1、打開電腦上的瀏覽器，點擊右上方的三條橫線標志。

F. ☆前端優化：瀏覽器緩存技術介紹

在前端開發中，性能一直都是被大家所重視的一點，然而判斷一個網站的性能最直觀的就是看網頁打開的速度。 其中提高網頁反應速度的一個方式就是使用緩存 。緩存技術一直一來在WEB技術體系中扮演非常重要角色，是快速且有效地提升性能的手段。

一個優秀的緩存策略可以縮短網頁請求資源的距離，減少延遲，並且由於緩存文件可以重復利用，還可以減少帶寬，降低網路負荷。

所以，緩存技術是無數WEB開發從業人員在工作過程中不可避免的一大問題。 在產品開發的時候我們總是想辦法避免緩存產生，而在產品發布之時又在想策略管理緩存提升網頁的訪問速度 。了解瀏覽器的緩存命中原理，是開發WEB應用的基礎，本文著眼於此，學習瀏覽器緩存的相關知識，總結緩存避免和緩存管理的方法，結合具體的場景說明緩存的相關問題。希望能對有需要的人有所幫助。

在實際WEB開發過程中，緩存技術會涉及到不同層、不同端，比如：用戶層、系統層、代理層、前端、後端、服務端等， 每一層的緩存目標都是一致的，就是盡快返回請求數據、減少延遲 ，但每層使用的技術實現是各有不同，面對不同層、不同端的優劣，選用不同的技術來提升系統響應效率。所以，我們首先看下各層的緩存都有哪些技術，都緩存哪些數據，從整體上，對WEB的緩存技術進行了解，如下圖所示：

本篇文章重點講的就是上面紅色框部分緩存內容。

當瀏覽器請求一個網站的時候，會載入各種各樣的資源，比如：HTML文檔、圖片、CSS和JS等文件。對於一些不經常變的內容，瀏覽器會將他們保存在本地的文件中，下次訪問相同網站的時候，直接載入這些資源，加速訪問。

那麼如何知曉瀏覽器是讀取了緩存還是直接請求伺服器？如下圖網站來做個示例：

第一次打開該網站後，如果再次刷新頁面。會發現瀏覽器載入的眾多資源中，有一部分size有具體數值，然而還有一部分請求，比如圖片、css和js等文件並沒有顯示文件大小，而是顯示了 from dis cache 或者 from memory cache 字樣。這就說明了，該資源直接從本地硬碟或者瀏覽器內存讀取，而並沒有請求伺服器。

瀏覽器啟用緩存至少有兩點顯而易見的好處： （1）減少頁面載入時間；（2）減少伺服器負載；

瀏覽器是否使用緩存、緩存多久，是由伺服器控制的 。准確來說，當瀏覽器請求一個網頁（或者其他資源）時， 伺服器發回的響應的「響應頭」部分的某些欄位指明了有關緩存的關鍵信息 。下面看下，HTTP報文中與緩存相關的首部欄位：

根據上面四種類型的首部欄位不同使用策略， 瀏覽器中緩存可分為強緩存和協商緩存 ：

當瀏覽器對某個資源的請求命中了強緩存時， 返回的HTTP狀態為200 ，在chrome的開發者工具的network裡面 size會顯示為from cache ，比如：京東的首頁里就有很多靜態資源配置了強緩存，用chrome打開幾次，再用f12查看network，可以看到有不少請求就是從緩存中載入的：

Expires是HTTP 1.0提出的一個表示資源過期時間的header，它描述的是一個絕對時間，由伺服器返回，用GMT格式的字元串表示 ，如：Expires:Thu, 31 Dec 2037 23:55:55 GMT，包含了Expires頭標簽的文件，就說明瀏覽器對於該文件緩存具有非常大的控制權。

例如，一個文件的Expires值是2020年的1月1日，那麼就代表，在2020年1月1日之前，瀏覽器都可以直接使用該文件的本地緩存文件，而不必去伺服器再次請求該文件，哪怕伺服器文件發生了變化。

所以， Expires是優化中最理想的情況，因為它根本不會產生請求 ，所以後端也就無需考慮查詢快慢。它的緩存原理，如下：

Expires是較老的強緩存管理header， 由於它是伺服器返回的一個絕對時間 ，在伺服器時間與客戶端時間相差較大時，緩存管理容易出現問題， 比如：隨意修改下客戶端時間，就能影響緩存命中的結果 。所以在HTTP 1.1的時候，提出了一個新的header， 就是Cache-Control，這是一個相對時間，在配置緩存的時候，以秒為單位，用數值表示 ，如：Cache-Control:max-age=315360000，它的緩存原理是：

Cache-Control描述的是一個相對時間 ，在進行緩存命中的時候， 都是利用客戶端時間進行判斷 ，所以相比較Expires，Cache-Control的緩存管理更有效，安全一些。

這兩個header可以只啟用一個，也可以同時啟用， 當response header中，Expires和Cache-Control同時存在時，Cache-Control優先順序高於Expires ：

此外，還可以為 Cache-Control 指定 public 或 private 標記。 如果使用 private，則表示該資源僅僅屬於發出請求的最終用戶，這將禁止中間伺服器（如代理伺服器）緩存此類資源 。對於包含用戶個人信息的文件（如一個包含用戶名的 HTML 文檔），可以設置 private，一方面由於這些緩存對其他用戶來說沒有任何意義，另一方面用戶可能不希望相關文件儲存在不受信任的伺服器上。需要指出的是，private 並不會使得緩存更加安全，它同樣會傳給中間伺服器（如果網站對於傳輸的安全性要求很高，應該使用傳輸層安全措施）。 對於 public，則允許所有伺服器緩存該資源 。通常情況下，對於所有人都可以訪問的資源（例如網站的 logo、圖片、腳本等）， Cache-Control 默認設為 public 是合理的 。

當瀏覽器對某個資源的請求沒有命中強緩存， 就會發一個請求到伺服器，驗證協商緩存是否命中，如果協商緩存命中，請求響應返回的http狀態為304並且會顯示一個Not Modified的字元串 ，比如你打開京東的首頁，按f12打開開發者工具，再按f5刷新頁面，查看network，可以看到有不少請求就是命中了協商緩存的：

查看單個請求的Response Header， 也能看到304的狀態碼和Not Modified的字元串，只要看到這個就可說明這個資源是命中了協商緩存，然後從客戶端緩存中載入的 ，而不是伺服器最新的資源：

【Last-Modified，If-Modified-Since】的控制緩存的原理，如下 ：

【Last-Modified，If-Modified-Since】都是根據伺服器時間返回的header，一般來說， 在沒有調整伺服器時間和篡改客戶端緩存的情況下，這兩個header配合起來管理協商緩存是非常可靠的，但是有時候也會伺服器上資源其實有變化，但是最後修改時間卻沒有變化的情況 ，而這種問題又很不容易被定位出來，而當這種情況出現的時候，就會影響協商緩存的可靠性。 所以就有了另外一對header來管理協商緩存，這對header就是【ETag、If-None-Match】 。它們的緩存管理的方式是：

Etag和Last-Modified非常相似，都是用來判斷一個參數，從而決定是否啟用緩存。 但是ETag相對於Last-Modified也有其優勢，可以更加准確的判斷文件內容是否被修改 ，從而在實際操作中實用程度也更高。

協商緩存跟強緩存不一樣，強緩存不發請求到伺服器， 所以有時候資源更新了瀏覽器還不知道，但是協商緩存會發請求到伺服器 ，所以資源是否更新，伺服器肯定知道。大部分web伺服器都默認開啟協商緩存，而且是同時啟用【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】，比如apache:

如果沒有協商緩存，每個到伺服器的請求，就都得返回資源內容，這樣伺服器的性能會極差。

【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】一般都是同時啟用，這是為了處理Last-Modified不可靠的情況。有一種場景需要注意：

比如，京東頁面的資源請求，返回的repsonse header就只有Last-Modified，沒有ETag：

協商緩存需要配合強緩存使用，上面這個截圖中，除了Last-Modified這個header，還有強緩存的相關header， 因為如果不啟用強緩存的話，協商緩存根本沒有意義 。

如果資源已經被瀏覽器緩存下來，在緩存失效之前，再次請求時，默認會先檢查是否命中強緩存，如果強緩存命中則直接讀取緩存，如果強緩存沒有命中則發請求到伺服器檢查是否命中協商緩存，如果協商緩存命中，則告訴瀏覽器還是可以從緩存讀取，否則才從伺服器返回最新的資源。其瀏覽器判斷緩存的詳細流程圖，如下：

G. ASP.net的整頁緩存，頁面部分緩存，應用程序緩存各自的優缺點是什麼

1.整頁緩存：優點：實現簡單，缺點：消耗伺服器內存
2.片段緩存：優點：節省內存
缺點：實現麻煩
3.應用程序緩存：優點：不局限緩存網頁，緩存對象多樣
確定：實現相對復雜

H. 頁面緩存是什麼

就是一些IE瀏覽痕跡吧，會佔用一定的空間，可以清除。

你可以到C:\WINDOWS\Temporary Internet Files的目錄下查看你的緩存文件。要清除IE緩存，打開「查看「菜單，選擇」Internet選項…然後查找Temporary Internet Files部分(在General Tab部分)並點擊「刪除文件」按鈕。IE將會問你是否要「刪除所有Temporary Internet Files文件夾中的文件？」點擊「OK」即可。

I. 怎麼用命令查看tomcat在memcached中的緩存

一、存儲命令

存儲命令的格式：

1
2

<command name> <key> <flags> <exptime> <bytes>
<data block>

參數說明如下：

<command name>
set/add/replace

<key>
查找關鍵字

<flags>
客戶機使用它存儲關於鍵值對的額外信息

<exptime>
該數據的存活時間，0表示永遠

<bytes>
存儲位元組數

<data block>
存儲的數據塊（可直接理解為key-value結構中的value）

1、添加

(1)、無論如何都存儲的set

這個set的命令在memcached中的使用頻率極高。set命令不但可以簡單添加，如果set的key已經存在，該命令可以更新該key所對應的原來的數據，也就是實現更新的作用。

可以通過「get 鍵名」的方式查看添加進去的記錄：

如你所知，我們也可以通過delete命令刪除掉，然後重新添加。

(2)、只有數據不存在時進行添加的add

(3)、只有數據存在時進行替換的replace

2、刪除

可以看到，刪除已存在的鍵值和不存在的記錄可以返回不同的結果。

二、讀取命令

1、get

get命令的key可以表示一個或者多個鍵，鍵之間以空格隔開

2、gets

可以看到，gets命令比普通的get命令多返回了一個數字（上圖中為13）。這個數字可以檢查數據是否發生改變。當key對應的數據改變時，這個多返回的數字也會改變。

3、cas

cas即checked and set的意思，只有當最後一個參數和gets所獲取的參數匹配時才能存儲，否則返回「EXISTS」。

三、狀態命令

1、stats

2、stats items

執行stats items，可以看到STAT items行，如果memcached存儲內容很多，那麼這里也會列出很多的STAT items行。

3、stats cachemp slab_id limit_num

我們執行stats cachemp 1 0 命令效果如下：

這里slab_id為1，是由2中的stats items返回的結果（STAT
items後面的數字）決定的；limit_num看起來好像是返回多少條記錄，猜的一點不錯，
不過0表示顯示出所有記錄，而n(n>0)就表示顯示n條記錄，如果n超過該slab下的所有記錄，則結果和0返回的結果一致。

通過stats items、stats cachemp slab_id limit_num配合get命令可以遍歷memcached的記錄。

4、其他stats命令

如stats slabs,stats sizes,stats reset等等使用也比較常見。

四、其他常見命令

1、append

在現有的緩存數據後添加緩存數據，如現有緩存的key不存在伺服器響應為NOT_STORED。

2、prepend

和append非常類似，但它的作用是在現有的緩存數據前添加緩存數據。

3、flush_all

該命令有一個可選的數字參數。它總是執行成功，伺服器會發送 「OK\r\n」
回應。它的效果是使已經存在的項目立即失效（預設），或在指定的時間後。此後執行取回命令，將不會有任何內容返回（除非重新存儲同樣的鍵名）。
flush_all
實際上沒有立即釋放項目所佔用的內存，而是在隨後陸續有新的項目被儲存時執行（這是由memcached的懶惰檢測和刪除機制決定的）。

flush_all 效果是它導致所有更新時間早於 flush_all 所設定時間的項目，在被執行取回命令時命令被忽略。

4、其他命令

memcached還有很多命令，比如對於存儲為數字型的可以通過incr/decr命令進行增減操作等等，這里只列出開發和運維中經常使用的命令，其他的不再一一舉例說明。

補充一則：簡單認識.net framework中的幾種緩存

web站點中緩存的重要性毋庸置疑。我想很多asp.net開發人員在開發web應用系統的時候優先考慮使用的緩存並不是第三方緩存解決方案（比如
分布式緩存memcached、redis等等），而應該是.net
framework已經提供的多種緩存解決方案。下面結合自己的開發經驗談談對.net framework中緩存的認識。

1、System.Web.Caching.Cache

估計大部分做過asp.net開發的人都用過這個命名空間下的緩存，我們可以直接使用HttpContext.Current.Cache實例而不
用實例化。當然這個命名空間下的Cache類是允許您實例化的，需要定製自己的緩存系統的當然可以完全自己控制如何初始化這個類。我在園子里看到過有很多
文章介紹Cache的CRUD輔助類庫大多數都是針對System.Web.Caching.Cache。

需要說明的是，我們還可以通過該命名空間下的HttpRuntime.Cache實現web、控制台、winform等不同表現形式下的緩存，而且
完全無需自己實例化。HttpRuntime.Cache是之前個人開發中使用比較多的一個類，現在比較偏愛.net
framework4.0中的增強型的緩存類MemoryCache。

2、Output Cache

眾所周知，輸出緩存主要分頁面輸出緩存和頁面部分緩存。說白了，就是緩存整個頁面的html或者部分html，本來沒什麼值得討論的，但是最近看到的這篇博客才恍然發現，想不到使用它還真是大有講究，我以前怎麼就沒有發現這個問題呢？看來發現問題和解決問題的能力同樣重要，有時候前者甚至更重要啊。

3、System.Runtime.Caching

現在個人開發中使用最多的類MemoryCache出自這個命名空間，使用前需要引用using
System.Runtime.Caching。MemoryCache繼承自ObjectCache, IEnumerable,
IDisposable，其中ObjectCache是個抽象類。用過MemoryCache的人都知道，這個MemoryCache有一個屬性叫
Default，通常可以像下面這樣使用：
private static ObjectCache memCache = MemoryCache.Default;

當然我們也完全可以通過public MemoryCache(string name, NameValueCollection config = null)構造函數初始化緩存對象。

接著我們可以在web.config文件中配置每個MemoryCache實例運行的內存使用配額方案和配額檢查周期，下面示例參考MSDN：
<system.runtime.caching>
<memoryCache>
<namedCaches>
<add name="Default" cacheMemoryLimitMegabytes="10" pollingInterval="00:02:00"/>
</namedCaches>
</memoryCache>
</system.runtime.caching>

這些配置意義在於可以明確指定每個MemoryCache實例運行的內存使用配額方案和配額檢查周期。比如我們可以通過配置來按需更改
MemoryCache.Default實例的內存配額（不知道緩存可用最大內存是多少，可能還是傳說中的800M左右）。緩存過期策略與其它的緩存框架
大同小異，與System.Web.Caching.Cache的不同只是名稱不叫CacheDependency，而叫ChangeMonitor，並且提供了基於文件和目錄的緩存依賴策略。關於緩存過期策略也比較有探討的必要，不過個人開發中比較偏重於數據緩存和替換，目前還沒有接觸和使用過比較完美的過期策略解決方案。

J. 在頁面上進行緩存後又要保證局部的數據不緩存，如何實現

頁面部分緩存是指輸出緩存頁面的某些部分，而不是緩存整個頁面內容。實現頁面部分緩存有兩種機制：一種是將頁面中需要緩存的部分置於用戶控制項（.ascx文件）中，並且為用戶控制項設置緩存功能（包含用戶控制項的ASP.NET頁面可設置也可不設置緩存）。這就是通常所說的「控制項緩存」。設置控制項緩存的實質是對用戶控制項進行緩存配置。主要包括以下3種方法：一是使用@ OutputCache指令以聲明方式為用戶控制項設置緩存功能，二是在代碼隱藏文件中使用PartialCachingAttribute類設置用戶控制項緩存；三是使用ControlCachePolicy類以編程方式指定用戶控制項緩存設置。另外，還有一種稱為「緩存後替換」的方法。該方法與控制項緩存正好相反，將頁面中的某一部分設置為不緩存，因此，盡管緩存了整個頁面，但是當再次請求該頁時，將重新處理那些沒有設置為緩存的內容。

使用@ OutputCache指令

控制項緩存與頁面輸出緩存的@ OutputCache指令既有相似之處，又有不同的方面。二者的共同點在於它們的設置方法基本相同，都是文件頂部設置包含屬性的@ OutputCache指令字元串。不同點包括以下兩個方面：一是控制項緩存的@ OutputCache指令設置在用戶控制項文件中，而頁面輸出緩存的@ OutputCache設置在普通ASP.NET文件中。二是控制項緩存的@ OutputCache指令只能設置6個屬性，Duration、Shared、SqlDependency、VaryByControl、VaryByCustom和VaryByParam。而在頁面輸出緩存的@ OutputCache指令字元串中設置的屬性多達10個。以上是設置控制項緩存時需要注意的問題。下面列舉了一些利用@ OutputCache指令設置控制項緩存的示例，其中重點說明了VaryByParam和VaryByControl等屬性應用。

用戶控制項中的@ OutputCache指令設置源代碼

＜%@ OutputCache Duration="120" VaryByParam="CategoryID;SelectedID"%＞

以上代碼設置用戶控制項緩存有效期時間是120秒，並且允許使用CategoryID和SelectedID參數來改變緩存。通過VaryByParam屬性設置，在伺服器緩存中可能存儲多個用戶控制項的實例。例如，對於一個包含用戶控制項的頁面，可能存在如下的URL鏈接。

包含用戶控制項的頁面的URL鏈接

http://localhost/mypage.aspx?categoryid=foo&selectedid=0
http://localhost/mypage.aspx?categoryid=foo&selectedid=1

當請求如上URL地址的頁面時，由於控制項中@ OutputCache指令的設置，尤其是屬性VaryByParam的設置，那麼在伺服器緩存中就會存儲兩個版本的用戶控制項緩存實例。

控制項緩存設置除了支持以上所述VaryByParam屬性外，還支持VaryByControl屬性。VaryByParam屬性基於使用POST或者GET方式發送的名稱/值對來改變緩存，而VaryByControl屬性通過用戶控制項文件中包含的伺服器控制項來改變緩存。下面是VaryByControl屬性的應用示例代碼。

用戶控制項中的@ OutputCache指令設置源代碼

＜%@ OutputCache Duration="120" VaryByParam="none" VaryByControl="Category" %＞

以上代碼設置緩存有效期是120秒，並且頁面不隨任何GET或POST參數改變（即使不使用VaryByParam屬性，但是仍然需要在@ OutputControl指令中顯式聲明該屬性）。如果用戶控制項中包含ID屬性為「Category」的伺服器控制項（例如下拉框控制項），那麼緩存將根據該控制項的變化來存儲用戶控制項數據。

如果讀者已經掌握了頁面輸出緩存的@ OutputCache指令設置方法，那麼控制項緩存的@ OutputCache指令也會迎刃而解，無非僅使用其中的6個屬性而已。然而，可能會產生疑問：如果ASP.NET頁面和其中包含的用戶控制項都通過@ OutputCache指令設置了緩存，那麼緩存該如何運行呢？

遇到這個問題時，應掌握以下個基本原則：一是ASP.NET允許在頁面和頁面的用戶控制項中同時使用@ OutputCache指令設置緩存，並且允許設置不同的緩存過期時間值。二是如果頁面輸出緩存過期時間長於用戶控制項輸出緩存過期時間，則頁面的輸出緩存持續時間優先。例如，如果頁面輸出緩存設置為100秒，而用戶控制項的輸出緩存設置為50秒，則包括用戶控制項在內的整個頁將在輸出緩存中存儲100秒，而與用戶控制項較短的時間設置無關。三是如果頁面輸出緩存過期時間比用戶控制項的輸出緩存過期時間短，則即使已為某個請求重新生成該頁面的其餘部分，也將一直緩存用戶控制項直到其過期時間到期為止。例如，如果頁面輸出緩存設置為50秒，而用戶控制項輸出緩存設置為100秒，則頁面其餘部分每到期兩次，用戶控制項才到期一次。