net緩存
A. 我想問一下,.net framework的緩存目錄怎麼找
32位系統在 C:\window\Mircrosoft.Net\Framework\v4.0.30319(.net的版本)\Temporary ASP.NET Files\root 下
64位系統將文件夾Framework改成Framework64
B. .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 的副本。其後再有請求時將提供緩存的輸出,直到緩存到期,這樣,性能有可能得到很大的提高(取決於需要多少開銷來創建原始頁面輸出 - 發送緩存的輸出總是很快,並且比較穩定)。
C. .NET中的緩存有幾種
.NET中的緩存(僅供參考)
一.Output Caching (輸出緩存)
當一個網頁頻繁被訪問的時候,可以通過把整個網頁緩存來提高執行效率。這樣做的優點是,當用戶再次訪問這個網頁的時候,被格式化好的HTML會被直接顯示。
Output Caching 定製的兩種方法:
1.基於底層的API技術
2.基於高層的@OutputCaching
一旦Output Caching 被定製過,那麼這個網頁就會在第一次被訪問的時候生成cache,直到請求過期為止。
二.Page Fragment Caching (回調緩存)
作為Output的緩存的附加功能,還提供一種緩存技術,專門用於緩存用戶控制項或者網頁中的一部分東西。可以指定沒一部分或者某一個區域不被緩存。
在頁面中,指定返回參數,來決定控制項被緩存的部分。使用語句VaryBym語句指定控制項更具參數來改變。
三.Data Caching (數據緩存)
ASP.NET提供了一種非常快捷的方法進行資料庫緩存,用戶可以非常方便的對頁面變數進行緩存。並以此提高程序效率。
一個頁面變數的緩存生命周期與應用程序的緩存生命周期相同。
同時對後台數據進行修改的時候,還需要對Cache進行相應的處理。
四.SQL Cache (配置連接池,提高數據緩存)
通過配置資料庫連接池,只有當資料庫數據被改變的時候,緩存才會改變。
五.Cache Configuration (配置緩存)
D. .net緩存
單獨寫個緩存操作類,如果需要則用這個類處理控制項源
E. ASP.NET緩存常見的4種方式有哪些
1、分布式緩存Memcached
2、內存緩存,此佔用伺服器資源
3、XML緩存,這種最為常見
4、DATATABLE緩存
F. vb.net如何實現緩存處理
首先~~需要確認的是,每次讀取花時間的問題~是在連接上還是在創建實例上。
如果是在創建實例上,需要做【單例模式】,建議所有數據創建在Mole中,並做全局變數。
Cache是一種B/S,的MVC方式。
緩存方式有很多~~~
一種是物理方式(做物理RAM內存開避空間)
一種是文件方式(做文件)
如文件方式,較常出現的如MVC的緩存,就是大概原理就是,把不經常用到(變化)的數據信息放到文件中,採用讀取文件的方式(比訪問數據快),存在指定或CurrentDir中。
如果想方便~需要追加一系列狀態標識~當訪問時,觸發變更,然後在讀取數據前,確認這個狀態是否變動,如果變動說明資料庫有變動,需要再次訪問資料庫。如果沒有變動,則讀取文件。
這種就叫緩存技術。
當然,我說的這種是比較簡單的,還是需要設計思想。
G. c#.NET緩存問題
CurrentContext.Response.AddHeader("pragma", "no-cache");
CurrentContext.Response.AddHeader("cache-control", "");
CurrentContext.Response.CacheControl = "no-cache";
這些是針對頁面數據的 頁面標記<html><這種
MemoryCache 是針對 你的資料庫數據,不需要多次訪問資料庫,在內存中操作快
H. .Net的Cache和Memcached有什麼優缺點
如果你的伺服器只有一台,且資料庫讀寫壓力不大,就沒必要使用Memcached。HttpRuntime.Cache是本地緩存,Memcached是分布式緩存,兩者的區別在於:
本地緩存
本地緩存可能是大家用的最多的一種緩存方式了,不管是本地內存還是磁碟,其速度快,成本低,在有些場合非常有效。
但是對於web系統的集群負載均衡結構來說,本地緩存使用起來就比較受限制,因為當資料庫數據發生變化時,你沒有一個簡單有效的方法去更新本地緩存;然而,你如果在不同的伺服器之間去同步本地緩存信息,由於緩存的低時效性和高訪問量的影響,其成本和性能恐怕都是難以接受的。
分布式緩存
前面提到過,本地緩存的使用很容易讓你的應用伺服器帶上「狀態」,這種情況下,數據同步的開銷09會比較大;尤其是在集群環境中更是如此!
分布式緩存這種東西存在的目的就是為了提供比RDB更高的TPS和擴展性,同時有幫你承擔了數據同步的痛苦;優秀的分布式緩存系統有大家所熟知的Memcached、Redis(當然也許你把它看成是NoSQL,但是我個人更願意把分布式緩存也看成是NoSQL),還有淘寶自主開發的Tair等。
對比關系型資料庫和緩存存儲,其在讀和寫性能上的差距可謂天壤之別;就拿淘寶的Tair來說,mdb引擎的單機QPS已在10w以上,ldb的也達到了5w~7w,而集群的性能會更高(目前uic所用的Tair集群QPS高達數十萬!)。
所以,在技術和業務都可以接受的情況下,我們可以盡量把讀寫壓力從資料庫轉移到緩存上,以保護看似強大,其實卻很脆弱的關系型資料庫。
I. .net 怎樣讀取緩存數據
具體問題具體分析,看你需要的數據是什麼,才能決定最佳的緩存結構.
舉個例子, 你資料庫里有個表,有全國各地的郵政編碼和地名,每次根據郵編去資料庫讀很慢,那麼你可以在程序啟動的時候把全部讀出來,然後在一個靜態類放一個Dictionary<string,string> , key是郵編, value是地名.
這樣只需要讀取一次資料庫,以後程序里需要使用都直接用這個Dictionary[郵編]就得到對應的地名了.
如果你的數據結構非常復雜,那麼可以使用復雜一點的結構,如果不是對象模型, 還可以用樹或其他結構, 總之是根據你要緩存的數據和使用來決定的. 你什麼也沒說,沒法給你個回答.
J. ASP.Net緩存問題
一樣的名字,當然只能得到最後的緩存。
這樣用緩存本身就不對,可以用用戶的sessionid來做緩存的key