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

microsoft_fly

1000并发用户，总共12000用户，这里的12000个用户是指什么用户，oracle的，还是？
我觉得从应用上合并用户，减少用户量比较好，否则你管理起来很累，容易出问题，因为应用程序的问题不是你能控制的

shooterchan

1000并发用户，总共12000用户并不算太多。大型的制造企业的EBS就有那么多用户，使用分节点、RAC、高配置服务器。
以LZ的硬件配置去支持1000并发用户够呛。
使用专用服务器模式，优化中间件连接池，尽可能把一些业务逻辑放到中间件上处理。当然数据库和中间件的服务器是分开的。

tolywang

原帖由 anlinew 于 2008-4-17 13:21 发表
程序自己开发？

不是，专门的开发人员来开发 。 01年自己开发过jsp , 呵呵， 用的tomcat(当时的版本好像最多支持75个连接) , 连接池倒是了解一些基本的，只是它如何接收客户端请求，然后如何协调这些用户请求与数据库通信不了解 ， 开发人员使用的是weblogic ，应该是使用了中间件 ，需要具体了解一下。

microsoft_fly

可以写个多线程的程序测试下

tolywang

原帖由 anlinew 于 2008-4-17 13:18 发表

中间件都提供连接池管理，通过池大小控制DB连接session

原理方面不是太懂

如果并发有 1200 个用户在使用web系统，共享池设置为 500 ，那么高峰时期连接到数据库的Session数最多就是 500 ，其他700个请求一直处于等待状态  ？

anlinew

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


不是，专门的开发人员来开发 。 01年自己开发过jsp , 呵呵， 用的tomcat(当时的版本好像最多支持75个连接) , 连接池倒是了解一些基本的，只是它如何接收客户端请求，然后如何协调这些用户请求与数据库通信不了解 ， 开发人员使用的是weblogic ，应该是使用了中间件 ，需要具体了解一下。

找架构师要个系统架构图看看就知道了，这样的一个系统不会没有架构图吧？
从tiptop变成自行开发，够有魄力的，挺有挑战性的

anlinew

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


原理方面不是太懂

如果并发有 1200 个用户在使用web系统，共享池设置为 500 ，那么高峰时期连接到数据库的Session数最多就是 500 ，其他700个请求一直处于等待状态  ？

一般来说1200个并发用户使用的web系统基本上是用不到500个并发的数据库连接的
具体情况还是视业务来定

tolywang

谢谢各位

看到一篇文章，说到了shared server , dedicated server 以及 程序段共享池  


       在建立Oracle数据库的时候，应该会在数据库建立助手向导上面看到这么一个选项，就是数据库的连接模式采用什么方式。在Oracle9i或者10g中，可以看到有2种连接模式，一种叫做专用服务器连接(dedicated server) ，另外一种叫做共享服务器连接(shared server)。下面我们来分类说一下这两种连接方式的不同点。

        专用服务器模式就是说每次在对Oracle进行访问的时候，Oracle服务器的Listener会得到这个访问请求，然后回为这个访问创建一个新的进程来进行服务。所以说，对于每一个客户端的访问，都会生成一个新的进程进行服务，是一种类似一对一的映射关系。这种连接模式的一个很重要的特点就是UGA（用户全局域）是存储在PGA（进程全局域）中的，这个特性也很好说明了当前用户的内存空间是按照进程来进行分配的。

        而另外的共享服务器连接则是一种在程序编写的时候通常会用到的连接池（pool）的概念。采用这种模式的话，在数据库的初始化的时候就会创建一批服务器连接的进程，然后把这些连接进程放入一个连接池来进行管理。初始化的池中的进程数量在数据库初始化建立的时候是可以手动设置的。在连接建立的时候，Listener首先接受到客户端的建立连接的请求，然后Listener去生成一个叫做调度器(dipatcher)的进程与客户端进行连接。调度器把把客户端的请求放在SGA（系统全局域）的一个请求队列中，然后再共享服务器连接池中查找有无空闲的连接，然后让这个空闲的服务器进行处理。处理完毕以后再把处理结果放在SGA的相应队列中。调度器通过查询相应队列，得到返回结果，再返回给客户端。这种连接模式的优点在于服务器进程的数量可以得到控制，不大可能出现因为连接人数过多而造成服务器内存崩溃。但是由于增加了复杂度以及请求相应队列，可能性能上有所下降。

        总之，谈到两种连接方式的优点和缺点，真的是各有千秋。在专用服务器模式下，优点就是每个用户都有一个连接，所以大家不至于有的应用占着连接造成别的客户的请求给挂起了。而最大的缺点在于内存管理上，因为随着连接数的增加，每增加一个连接，就要分配一份PGA，如果增加10000个连接，那就是10000个PGA要提供，内存很容易吃爆掉。而共享连接方式优点在于连接数量固定，所以内存数量不会占用很多，不过在数据库初始化的时候，共享服务器就要初始化好，比如有100个共享服务器，由于共享连接模式下，UGA是分配在PGA中的，所以初始化的时候需要初始化比较多的内存，也就是那100个UGA的内存。另外共享服务器还有一个优点就是很多数据库高级连接特性都要求使用共享服务器，所以有时候为了使用这些特性迫不得已只好设定为共享服务器连接模式。共享服务器的最大的缺点还是在于数据仓库模式下运行的时候，如果有大量的请求需要长时间占用服务器，那么就会造成很多别的请求的挂起，导致整个服务器性能的降低。另外，在有些应用服务器提供了连接池的时候，比如J2EE中经常有应用服务器的连接池，比如Weblogic的啊，还有开源的DBCP以及C3P0等等。在有这些连接池的时候，共享服务器对于性能上反而造成了累赘。另外，有时候在使用共享服务器的时候，由于数据事务处理不及时，而占住服务器的进程试图锁定前面事务没有处理的数据，会造成数据库的死锁，特别是如果没有设定连接锁定超时的话，只能通过DBA上数据库杀进程的方式来解决了。不过也有这种的最佳方案，那就是混合模式，也就是对于同一个数据库服务器，既有专用服务器，也有共享服务器，共享服务器用来处理那种事务性很强的活。而专用服务器用来对付那些比较耗时间和资源的请求。当然，也要看到时候的实际情况如何再做决定，两者没有绝对的哪种好哪种不好的差别。

foreverlee

原帖由 anlinew 于 2008-4-17 14:27 发表

一般来说1200个并发用户使用的web系统基本上是用不到500个并发的数据库连接的
具体情况还是视业务来定

如果应用中没有很大的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.

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

foxmile

我看看我这里的环境。看有没有借鉴意义

[ 本帖最后由 foxmile 于 2008-4-17 17:36 编辑 ]