在傳統的ASP內存泄漏中實現對象緩存

我試圖在傳統的ASP站點中實現不同的緩存實現，以便在繁忙流量期間卸載數據庫。在傳統的ASP內存泄漏中實現對象緩存

我的做法是這樣的：

，我後來在商店的JScript對象中

<object id="SIZE_LIST" progid="System.Collections.HashTable" runat="Server" scope="Application"></object>

這給了我一個哈希表全球對象創建Global.asa中的一個全局Hashtable對象，我以特定的時間間隔替換HashTable的內容。大小隻會有所不同，但我會做。每次刪除（）和.Add（）所有對象。

這很有效，除此之外，經過一段時間後，應用程序的內存分配會變得很高，從而導致會話的非理性行爲。它會「忘記」會話，但不會在global.asa中調用OnSessionStart（）。因此，爲訪客留下一個空的會話集合。

我能以某種方式改善內存重新分配過程嗎？有沒有更好的對象緩存方法？

我曾嘗試使用純文本文件與json序列化的數據，但反序列化的是很多開銷。我想過二進制序列化，但我不確定在傳統的ASP中是否有可能。

來源

2009-08-10 jishi

與常規的「Scripting.Dictionary」相比使用.NET HashTable的原因是什麼？

當你做傳統的ASP時，爲什麼普通的COM對象不夠用？

來源

2009-08-10 17:05:06 Tomalak

afaik Scripting.Dictionary和IISSample.LookupTable綁定到它們只能存儲原始數據類型（字符串和數字）的事實。這會讓我再次需要序列化。當然，我不需要反序列化所有的東西。 LookupTable也不支持動態變化（我知道我們有Scripting.Dictionary的問題，但我不能肯定地說） – jishi 2009-08-11 07:25:39

我想這是問題：http://www.4guysfromrolla.com /aspfaqs/ShowFAQ.asp?FAQID=129 – jishi 2009-08-11 07:30:55

Scripting.Dictionary可以存儲您喜歡的任何值。對象引用*和*原始值。僅限制：鍵必須是字符串。 – Tomalak 2009-08-11 08:54:01

不要試圖重新發明輪子。使用memcache。它免費且易於安裝。作爲獎勵有ttl（生存時間）和超出服務器邊界的作品

來源

2009-08-10 17:44:33 Toad

從我所學到的，memcached需要至少2個單獨的服務器。這對於像這樣簡單的任務來說是一個相當大的設置。它也是基於網絡的，意味着比將其存儲在RAM中的開銷更大。當然，正如你所說，更具可擴展性，如果我創建1個設置，我可以將它用於多個站點，但我不確定在不久的將來我是否有這種需求。 – jishi 2009-08-11 07:27:58

memcache可以在同一臺機器上運行。你是對的，有點開銷。但與不必每次再次查詢的收益相比，這是微不足道的。 – Toad 2009-08-11 08:32:13

這只是一個猜測，但它可能是因爲你將JScript對象存儲到.net哈希中，你仍然可以保留對該對象垃圾收集從來沒有得到正確完成其工作的機會。

我以前使用過JSON字符串的應用程序，在重新提供數據時快速地進行處理和評估。

如果您擔心數據過期，可以使用XMLHTTPRequest服務器端（令人驚訝的快速）調用aspx頁面，該頁面將執行搜索並返回JSON字符串。 aspx頁面可以使用.net奇妙的緩存爲您處理緩存，甚至可以使用SharpZipLib壓縮JSON字符串，然後將其存儲在緩存中，以便更多地減少內存佔用。這也是將XML文件存儲在緩存中的一個很好的技巧（600K在0.0016秒內降至25K！）

我們以前在項目中使用過上述所有項目，但並不完美，但是基於限制和遺留代碼。而且它們都非常快速（不是由.net標準確定，而是爲了真正快速地編寫腳本）。

來源

2009-08-11 12:25:25

好吧，當我們嘗試在應用程序中存儲json字符串時，我們遇到了相同的內存問題。即使eval速度非常快，但在CPU上也非常激烈。我們也用SessionStart的東西得到了這個奇怪的行爲。這一切都取決於我們在這種情況下存儲在Application中的數據量，所以它看起來似乎無懈可擊，或者我們做錯了什麼。當w3wp.exe開始使用大約300MB時，我們開始爲某些訪問者獲取這個間歇性問題。 – jishi 2009-08-11 14:11:02

如果CPU的密集程度在這裏或那裏不是那麼高，那麼CPU的密集程度就沒有問題了。是的，你正在做的工作太多了，你將不得不重新審視這個解決方案。可能是因爲你試圖對緩存做太多的工作。你真的需要緩存一切嗎？如果你這樣做，那麼你可能必須走建設自定義函數的路線來從應用程序重建對象而不是評估它們（參見http://stackoverflow.com/questions/1196525/classic-asp-store-objects-in-the -session對象/ 1206639＃1206639）。我知道你說過你不想這樣做，但你現在的選擇是有限的 – 2009-08-12 11:34:52

我會選擇更低技術的方法，並將每個對象（與字符串鍵）分開存儲在Application對象中。這樣你就不會從腳本引擎的角度看到一個巨大的對象。你認爲這會有所幫助嗎？

來源

2009-12-21 23:08:46

嘗試過了，搞亂Application也不是一個好主意。從應用程序連續寫入/讀取往往會耗盡所有內存和會話垃圾的麻煩。 – jishi 2009-12-30 15:12:08

在傳統的ASP內存泄漏中實現對象緩存

回答

相關問題