在经典的 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>

这给了我一个全局 HashTable 对象，我在某些时间间隔替换 HashTable 的内容.大小只会略有不同，但我每次都会执行 .Remove() 和 .Add() 所有对象.

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.

这很有效，除了在一段时间后，应用程序的内存分配变得很高，导致会话的非理性行为.它会忘记"会话，但不会调用 global.asa 中的 OnSessionStart().因此，给访问者留下一个空的 Session-collection.

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?

我曾尝试将纯文本文件与 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屋！