在会话变量中存储对象 - 究竟为什么不呢？ [英] Storing objects in Session Variables - exactly why not?

问题描述

我已经阅读（并阅读！）您不应该在会话变量中存储对象。

我已经阅读了这些理由：


- 对象占用的内存在会话时间之前可能无法释放

out。最好只在实际使用时创建对象。


- 导致性能不佳，因为创建对象的线程必须为b
服务所有请求。


假设我可以忍受记忆和性能的影响（一个很大的if，

但让我们假设一分钟），还有什么其他的原因是什么？


MJ。

I''ve read (and read!) that you shouldn''t store objects in Session variables.
I''ve read these reasons:

- The object takes up memory that may not be freed until the session times
out. Better to create the object only when you actually use it.

- Causes poor performance because the thread that created the object has to
service all requests for it.

Assuming I can live with the memory and performance implications (a big if,
but let''s assume it for a minute), what other reasons are there?

MJ.

推荐答案

反对这种情况的原因随服务器而减少功率增长 - 显然如果你有一个非常大的服务器，你可以处理内存使用问题。通过确保您只使用免费的

线程对象（例如MSXML.FreeThreadedDomDocument），可以轻松克服
线程问题。


管理它们可能会有点麻烦，而且调试可能很麻烦，但是如果你认为你可以处理它，那就和内存一样

要求，然后随意。只要确保你知道你将最终使用多少内存
。

-

Jason Brown

Microsoft GTSC，IIS

此帖子按原样提供。没有保证，也没有赋予任何权利。


" mjkahn" < MJ **** @ discussions.microsoft.com>在留言中写道

新闻：6D ********************************** @ microsof t.com ...

The reasons against this diminish as server power grows - obviously if you
have a really hefty server, you can handle the memory usage issues. THe
threading issue is fairly easily overcome by making sure you only use free
threaded objects (such as MSXML.FreeThreadedDomDocument).

It can get to be a bit of a chore to manage them too, and debugging can be
tricky, but if you think you can handle that, along with the memory
requirements, then feel free. Just make sure you have an idea of how much
memory you''re going to end up using.
--
Jason Brown
Microsoft GTSC, IIS

This posting is provided "AS IS" with no warranties, and confers no rights.

"mjkahn" <mj****@discussions.microsoft.com> wrote in message
news:6D**********************************@microsof t.com...

我已经阅读（并阅读！）你不应该在Session
变量中存储对象。
我读过这些原因：

- 对象占用的内存在会话时间之前可能无法释放。最好只在实际使用时才创建对象。

- 导致性能不佳，因为创建对象的线程已经为所有请求提供服务。

假设我可以忍受记忆和性能的影响（如果这是一个很大的
，但让它假设一分钟），还有其他原因吗？

MJ。

I''ve read (and read!) that you shouldn''t store objects in Session
variables.
I''ve read these reasons:

- The object takes up memory that may not be freed until the session times
out. Better to create the object only when you actually use it.

- Causes poor performance because the thread that created the object has
to
service all requests for it.

Assuming I can live with the memory and performance implications (a big
if,
but let''s assume it for a minute), what other reasons are there?

MJ.

我在会话和应用程序内存中使用ADO对象超过3年了

没有任何问题。拥有ADO.Connection对象的共享池

通过global.asa分配给新客户端，证明比在运行时分配和实例化对象要快得多。
。 br />

线程问题我没有注意到，虽然我们总是有很多conqurrent

用户，服务器cpu负载<6％avr （3ghz系统）。


当然内存使用率非常高，网络的应用程序池使用了大约

1 - 1.5gb。但是，嘿，现在记忆很便宜;-)


- 托马斯

" mjkahn" < MJ **** @ discussions.microsoft.com>在留言中写道

新闻：6D ********************************** @ microsof t.com ...

i''m using ADO objects in Session and Application memory for over 3 years now
without any problems at all. having a shared pool of ADO.Connection objects
that is assigned to new clients through global.asa proofed to be much faster
than allocate and instantiate the objects at runtime.

threading issue i haven''t noticed, although we have quite a few conqurrent
users on all the time, server cpu load is <6% avr (3ghz system).

of course memory usage is very high, the web''s application pool uses around
1 - 1.5gb. but hey, memory is cheap nowadays ;-)

- thomas
"mjkahn" <mj****@discussions.microsoft.com> wrote in message
news:6D**********************************@microsof t.com...

我已经阅读（并阅读！）你不应该在Session
变量中存储对象。
我读过这些原因：

- 对象占用的内存在会话时间之前可能无法释放。最好只在实际使用时才创建对象。

- 导致性能不佳，因为创建对象的线程已经为所有请求提供服务。

假设我可以忍受记忆和性能的影响（如果这是一个很大的
，但让它假设一分钟），还有其他原因吗？

MJ。

I''ve read (and read!) that you shouldn''t store objects in Session
variables.
I''ve read these reasons:

- The object takes up memory that may not be freed until the session times
out. Better to create the object only when you actually use it.

- Causes poor performance because the thread that created the object has
to
service all requests for it.

Assuming I can live with the memory and performance implications (a big
if,
but let''s assume it for a minute), what other reasons are there?

MJ.

Thomas写道：

我在会话和应用程序内存中使用ADO对象现在3年没有任何问题。拥有一个共享的ADO.Connection对象池，通过
global.asa分配给新客户端，证明比在运行时分配和实例化对象要快得多。


你究竟是怎么决定的？

线程问题我没有注意到，虽然我们有很多
conqurrent用户所有的时间，服务器CPU负载都是< 6％avr（3ghz
系统）。当然内存使用率非常高，web的应用程序池使用大约1 - 1.5 GB。但是，嘿，内存现在很便宜; - ）

i''m using ADO objects in Session and Application memory for over 3
years now without any problems at all. having a shared pool of
ADO.Connection objects that is assigned to new clients through
global.asa proofed to be much faster than allocate and instantiate
the objects at runtime.
And exactly how did you determine this?

threading issue i haven''t noticed, although we have quite a few
conqurrent users on all the time, server cpu load is <6% avr (3ghz
system).
of course memory usage is very high, the web''s application pool uses
around 1 - 1.5gb. but hey, memory is cheap nowadays ;-)

通过这样做，你已经阻止了OLE DB会话池的使用，如果

你还没有改变ADO的线程模型从公寓到

免费线程（如果使用Jet就不应该这样做），你已经序列化了所有

您的数据库访问权限。


仅仅因为您无法察觉性能问题并不意味着一个人不存在。

不存在。


Bob Barrows

-

Microsoft MVP - ASP / ASP.NET

请回复新闻组。这个电子邮件帐户是我的垃圾邮件陷阱所以我

不经常检查它。如果您必须离线回复，请删除

无垃圾邮件

By doing this, you''ve prevented the use of OLE DB session pooling, and, if
you haven''t changed the threading model of ADO from apartment to
free-threaded (which you should not do if using Jet), you''ve serialized all
of your database access.

Just because you cannot perceive a performance issue does not mean one does
not exist.

Bob Barrows
--
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don''t check it very often. If you must reply off-line, then remove the
"NO SPAM"

这篇关于在会话变量中存储对象 - 究竟为什么不呢？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！