1000并发用户，总共12000用户，9i或10g用啥模式好一些(MTS,Dedicated)?

tolywang · 发表于 2008-4-17 17:28

原帖由 foreverlee 于 2008-4-17 16:56 发表

如果应用中没有很大的transation的话在App server使用中间件比如Bea的weblogic设置100-150左右的connection pool size就可以支持你们1500个在线用户了

The key here in you case is to shorten the transation from the DB side and The middleware can handle the connection between App server and DB server by using connection pool mechanism which is a collection of long spanning sessions that you can moniter from DB side.

thanks, 是不是一旦用户连接没有transaction 执行，这个连接资源就会被释放，还是必须人为去干预 (比如连接30秒没有任何transaction 连接占用的资源将会释放 ) ？

foreverlee · 发表于 2008-4-17 18:11

原帖由 tolywang 于 2008-4-17 17:28 发表

thanks, 是不是一旦用户连接没有transaction 执行，这个连接资源就会被释放，还是必须人为去干预 (比如连接30秒没有任何transaction 连接占用的资源将会释放 ) ？

虽然我不是搞middleware的.

但是从我使用weblogic的经历上看

其实可以打这样一个比方:

现在App server 和 DB Server 在一条大河的两岸 middleware要做的就是为这条大河建立桥梁.
具体建立多少座桥梁由connection pool 里面的connection objects的多少决定,
而通过设置中间件里的connection pool size 这个参数可以在设置connection objects的多少.
每座桥梁存在的时间从middleware启动后就开始存在中间件通过connection pool mechnism管理这些conn objects（桥梁）
应用程序通过获取一个conn object连到数据库之后的事情DBA就都清楚了.

所以在middleware里设置了多少个connection objects 就会在DB server端起多少个PGAs

你现在这里1000并发用户，总共12000用户也就是说有1000个requests要同时被applicaion发出请求一个connection object 从而过河到DB端.
但是考虑到如果transation很小的话(applicaion如果很好的控制了commit操作) 那么每个connection object 被持有的时间会是很短的.

所以我说你这个case的核心是applicaion是否很好的控制了transation的大小？

foreverlee · 发表于 2008-4-17 18:14

对了还有很重要的我刚才忽视了就是select操作也要占用一个conn object
所以现在就要看appplicaion 中是否有很多大的transaction和是否有很多response time很长的sql.

[ 本帖最后由 foreverlee 于 2008-4-17 18:59 编辑 ]