实现对象缓存在传统的ASP的内存泄漏 [英] Implement object-caching in classic ASP memory-leaking

问题描述

我试图实现以交通繁忙期间卸载数据库在传统的ASP网站不同的缓存的实现。

I have tried to implement different caching-implementations in a classic ASP site in order to offload the database during heavy traffic.

我的做法是这样的：

Global.asa中创建一个全局Hashtable对象，我后来就在店内的JScript对象

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

这给了我一个全局哈希表的对象，我在一定的时间间隔更换哈希表的内容。大小只会稍有不同，但是，但是我做的一个.remove（）和。新增（）中的所有对象，每次

This gives me a global HashTable-object that I at certain time-intervals replace the content of the HashTable. The size will only vary slightly, but I however do .Remove() and .Add() all objects, each time.

这工作得很好，除了一个事实，即在一定时间后，应用程序的memoryallocation变高，使会议的非理性行为。它会忘记会话，但在global.asa中没有援引OnSessionStart（）。为此，留给游客一个空会话集合。

This works very well, besides from the fact that after a certain time, the memoryallocation of the app gets to high, giving irrational behaviour of the sessions. It will "forget" sessions, but not invoke OnSessionStart() in global.asa. Therefor, leaving visitors with an empty Session-collection.

我可以以某种方式提高内存再分配过程？是否有对象缓存任何更好的办法？

Can I somehow improve the memory-reallocation-process? Is there any better approach for object-caching?

我已经使用普通TEXTFILES使用JSON序列化的数据试过，但该反序列化是开销很大。我想到了二进制序列化，但我不知道，如果它甚至有可能在传统的ASP。

I have tried using plain textfiles with json-serialized data, but the deserialization of that is to much overhead. I thought about binary-serialization, but I'm not sure if it's even possible in classic ASP.

推荐答案

什么是比普通的Scripting.Dictionary使用.NET HashTable的原因是什么？

What are the reasons for using a .NET HashTable over a regular "Scripting.Dictionary"?

当你做传统的ASP，为什么一个普通的COM对象是不够的？

When you do classic ASP, why would a normal COM object not be enough?

这篇关于实现对象缓存在传统的ASP的内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！