C
cAkk
Unregistered / Unconfirmed
GUEST, unregistred user!
以前你曾经和我争论过,在asp中是否应该把一个数据库的连接放在sessoin里面
以节省系统开销,当时我说最好是即用即create/close,你和另外一个大虾说
应该放在session里,说是可以减轻server的负担.
当时我凭直觉认为这样肯定不行,但是没有合适的理由来反驳,现在我终于
有资料来反驳你了.
下面的文章来自www.chinasp.com,作者是joy asp版鼎鼎大名的batman:
===========================================================
有关将ADO对象保存进Application中的两点看法，欢迎大家踊跃发言呀！【帮困在edu网内的batman转贴】
--------------------------------------------------------------------------------
[飞鸟] 于 99-11-24 23:33:57 加贴在 Joy ASP：
下面是我的意见，大家可以踊跃发言呀，因为这个问题确实是个
很重要的问题的。
如果你要是把ADO的对象放在Application中的话，
主要面临下面这两个问题：
1。保存在Application中的对象必须要支持自由线程(Free-threading)，
或则说它必须是一个Free-或则Both-threaded的对象。
例如你不能够把VB生成的组件放到Application变量中，但是你可以把它放到
Session中，把一个Apartment-threaded的对象放在Session中意味着
只能把一个Apartment-threaded的对象放在Session中意味着
只能够是建立该session对象的人才能够访问它。
所以如果你把对象建立在session中的话，IIS就不能够
执行该session对象的性能管理了（因为两者不在一个线程里面，
并且任何想访问这个对象的页面就必须得一直处于等待状态，
直到最初的那个线程完成服务为止。这个过程如果引用老外的原话就是
This can kill any chance of scaling your application well.
在默认的状态下，ADO是一个Apartment-threaded的对象,这主要是因为
一些OLEDB Providers是不能够保证自己是一个安全的线程.但是在ADO
的安装目录里面有一个注册表文件，这个文件可以将ADO转换成
Both-threaded模式,如果你进行了这个转换的话，那么就可以将
ADO的对象（包括Connction,RecordSet,Command等）保存在
Application和Session中。
呵呵，这时也许你会认为这很好呀，我这下可以通过把这些对象
保存在Application或则sesion中来提高我整个系统的运行性能了呀，
其实这是根本就不必要的.有人可能都这么想过，将一个Connection
对象保存到Application中，就可以免去复杂和冗长的数据库连接操作了，
如果将一个Connection连接建立到Application或则session中当我再次
使用这个连接的时候会回节约大量的时间。
是的，可以说确实把一个连接(Connection)对象缓存到Application中
是可以解决一些时间的，但是这里面一个最大的问题，还是我前面所说的，
当你缓存一个连接对象时就意味着你的这个连接将永远不会被关闭，
于是数据库的连接池（connection pooling）将工作在很低的效率下，
要知道当初之所以有数据库连接池这个东东的初衷，就是为了
降低在服务端所耗费的资源，如果你静态的把一个连接缓存到
Application中，这些资源将永远不会被释放掉，也就是说，这将几乎不
能够减少服务端耗费的资源，相反，这将增加在服务端耗费的资源，
因为每次你缓存一个对象就使用一次服务端的资源，
当用户很多的时候，频繁的操作很多的时候，繁重的使用网站服务端的
资源将非常严重的降低整个Web Server的性能。这和数据库的操作相比是
得不偿失的，因为如果网站的负担太重的话，我完全可以把数据库放到另外
一台（或则多台）专门的数据库服务器（就是网站服务器和数据库服务器分离）
这个在专门的大型网站也是很常见的处理方法.
但是如果你把连接对象放到Application中去的话，那么就是Web Server
和Database Server分了，Web Server的负担还是不可能减轻的。
说了那么多，我再顺便补充一点：
你也许会想，那么我不把连接(Connection)对象放到Application或则Session中了，
我放RecordSet可以把，呵呵。
这个你可要小心哦，如果只要将ADO由Apartment-threaded该变成Both-threaded,
应该是没有理由不用的了。
但是，如果你的RecordSet很大的话，千万不能够忘记我在上面所说的，
这也会加重Web Server的内存的耗费量的。
2。第二点也许可以使用ADO的GetRows把数据库中的数据放到一个数组中，这样
也许会减轻频繁查询数据库的烦恼，但是同样的一点，你减轻了数据库服务端的
访问量自然就会增加Web Server的负荷（因为不论你使用哪种技术，如果数据量很大的话，耗费Web Server的内存也越多的）
总的来说，考虑这些问题的时候，我们必须要根据实际情况来定的，特别是
考虑如何合理运用服务端的资源这个问题上，不能光为了减轻数据库服务器的
压力，就把所有的负担都让Web服务器一个人来扛，毕竟客户最终浏览的是你的
Web Server而不是你的Database Server，而且增加一个Database Server远远要比增加一个Web Server容易得多的，呵呵。
以节省系统开销,当时我说最好是即用即create/close,你和另外一个大虾说
应该放在session里,说是可以减轻server的负担.
当时我凭直觉认为这样肯定不行,但是没有合适的理由来反驳,现在我终于
有资料来反驳你了.
下面的文章来自www.chinasp.com,作者是joy asp版鼎鼎大名的batman:
===========================================================
有关将ADO对象保存进Application中的两点看法，欢迎大家踊跃发言呀！【帮困在edu网内的batman转贴】
--------------------------------------------------------------------------------
[飞鸟] 于 99-11-24 23:33:57 加贴在 Joy ASP：
下面是我的意见，大家可以踊跃发言呀，因为这个问题确实是个
很重要的问题的。
如果你要是把ADO的对象放在Application中的话，
主要面临下面这两个问题：
1。保存在Application中的对象必须要支持自由线程(Free-threading)，
或则说它必须是一个Free-或则Both-threaded的对象。
例如你不能够把VB生成的组件放到Application变量中，但是你可以把它放到
Session中，把一个Apartment-threaded的对象放在Session中意味着
只能把一个Apartment-threaded的对象放在Session中意味着
只能够是建立该session对象的人才能够访问它。
所以如果你把对象建立在session中的话，IIS就不能够
执行该session对象的性能管理了（因为两者不在一个线程里面，
并且任何想访问这个对象的页面就必须得一直处于等待状态，
直到最初的那个线程完成服务为止。这个过程如果引用老外的原话就是
This can kill any chance of scaling your application well.
在默认的状态下，ADO是一个Apartment-threaded的对象,这主要是因为
一些OLEDB Providers是不能够保证自己是一个安全的线程.但是在ADO
的安装目录里面有一个注册表文件，这个文件可以将ADO转换成
Both-threaded模式,如果你进行了这个转换的话，那么就可以将
ADO的对象（包括Connction,RecordSet,Command等）保存在
Application和Session中。
呵呵，这时也许你会认为这很好呀，我这下可以通过把这些对象
保存在Application或则sesion中来提高我整个系统的运行性能了呀，
其实这是根本就不必要的.有人可能都这么想过，将一个Connection
对象保存到Application中，就可以免去复杂和冗长的数据库连接操作了，
如果将一个Connection连接建立到Application或则session中当我再次
使用这个连接的时候会回节约大量的时间。
是的，可以说确实把一个连接(Connection)对象缓存到Application中
是可以解决一些时间的，但是这里面一个最大的问题，还是我前面所说的，
当你缓存一个连接对象时就意味着你的这个连接将永远不会被关闭，
于是数据库的连接池（connection pooling）将工作在很低的效率下，
要知道当初之所以有数据库连接池这个东东的初衷，就是为了
降低在服务端所耗费的资源，如果你静态的把一个连接缓存到
Application中，这些资源将永远不会被释放掉，也就是说，这将几乎不
能够减少服务端耗费的资源，相反，这将增加在服务端耗费的资源，
因为每次你缓存一个对象就使用一次服务端的资源，
当用户很多的时候，频繁的操作很多的时候，繁重的使用网站服务端的
资源将非常严重的降低整个Web Server的性能。这和数据库的操作相比是
得不偿失的，因为如果网站的负担太重的话，我完全可以把数据库放到另外
一台（或则多台）专门的数据库服务器（就是网站服务器和数据库服务器分离）
这个在专门的大型网站也是很常见的处理方法.
但是如果你把连接对象放到Application中去的话，那么就是Web Server
和Database Server分了，Web Server的负担还是不可能减轻的。
说了那么多，我再顺便补充一点：
你也许会想，那么我不把连接(Connection)对象放到Application或则Session中了，
我放RecordSet可以把，呵呵。
这个你可要小心哦，如果只要将ADO由Apartment-threaded该变成Both-threaded,
应该是没有理由不用的了。
但是，如果你的RecordSet很大的话，千万不能够忘记我在上面所说的，
这也会加重Web Server的内存的耗费量的。
2。第二点也许可以使用ADO的GetRows把数据库中的数据放到一个数组中，这样
也许会减轻频繁查询数据库的烦恼，但是同样的一点，你减轻了数据库服务端的
访问量自然就会增加Web Server的负荷（因为不论你使用哪种技术，如果数据量很大的话，耗费Web Server的内存也越多的）
总的来说，考虑这些问题的时候，我们必须要根据实际情况来定的，特别是
考虑如何合理运用服务端的资源这个问题上，不能光为了减轻数据库服务器的
压力，就把所有的负担都让Web服务器一个人来扛，毕竟客户最终浏览的是你的
Web Server而不是你的Database Server，而且增加一个Database Server远远要比增加一个Web Server容易得多的，呵呵。
