【求助】并发访问导致系统挂机

Question

目前我们开发的系统面临用户数量较多，存在严重的并发访问瓶颈问题。
主要表现在以下几个方面：
1、并发访问（1秒钟内20多个用户登录），抛出异常“600s”错误，导致Weblogic直接挂起；
2、大量用户登录系统后非正常退出，Session无法得到及时释放，系统内存溢出，直接崩溃；
3、没有优化的SQL语句执行时间偏长时，直接导致数据库连接超时，后期并发访问直接崩溃。
请教大家有什么良方。

Answer 1

1.weblogic调优，这个得根据实际情况，
最少也整个集群吧
2.session超时时间设短些
或者在页面上做文章
3.sql语句优化也根据实际情况调整
建索引，提高数据库性能等，
不一而足

Answer 2

1、1秒钟内20多个用户登录
  weblogic不会这么脆弱的,你的程序要优化，最起码查询字段要加索引..
  还有一些weblogic优化配置,1秒20 这不算太高的并发 webligc完全能支持
2、session超时..还有session中不要防止太多的数据,数据可以使用cookie或者缓存代替
3、索引最重要,有没有的情况下一条查询可能差别20多秒(大数据)，还有 exist代替in等常用的优化

Answer 3

性能调优如抽丝去病，确实不太容易。重构要小心。要用测试代码做点防护。具体的东西提两点：
1、连接超时，说明Server潜力可能还是有的，只是锁的粒度大了点，看看有没有事务控制细粒化的可能性。
2、关于Session，剥离一些Session中数据到请求域或应用域、数据库中。

Answer 4

谢谢大家，给我帮助很大。
目前在做Weblogic参数调优和负荷压力测试。1、一直在对Session减肥，因为系统涉及的模块和权限很多，所以Session中带的这方面的数据较大；
2、用户登录处为多层多级模式，所以采用Ajax实现，感觉多用户同时登陆时对数据库的冲击很大；
3、exist代替in等常用的优化。这个也是很恼火的，因为in后面带的数组中的内容并不是某个可以select的集合，所以只好采用 id in ('1','2','5')/**1000个**/ or id in ('100','121','131')

Answer 5

我来说下吧，BEA8.1 9.2 10都用过，我做的项目大多也都是机遇weblogic的项目。
  每秒20用户登录，这个确实不是Weblogic的瓶颈，只要程序不垃圾轻松上100的。楼主可能需要优化的如下：
  1、使用绑定变量，减少数据库硬解析的次数，因为这个解析过程是串行过程，所以为了等待资源Sql在运行前回等待解析，这个是很大的性能瓶颈。
  2、查询索引，像登录这种的function就给Username加上索引吧
  3、去除你sql里面的in，因为你哪怕写成“id=1 or id=2 or id=5”也要比你写成“id in ('1','2','5')”要好的多。因为ID应该是你的主键吧，主键都是带索引的，但是你使用了in就相当于在索引列增加了函数，导致索引失效（函数索引除外）。
  4、最后一点属于设计上的问题，做Weblogic的集群，你既然选择了用BEA肯定要做集群的吧，否则用这么重量的做啥。做好集群，多个应用一起来分担压力。做好Cluster，就算一个挂了，另外一个可以先支撑一下
   

Answer 6

谢谢。1、使用绑定变量，减少数据库硬解析的次数
=================================
不知你是不是让我们多用存储过程或PreparedStatement，其实在批量操作方面（查询除外）几乎都是用的PreparedStatement。2、像登录这种的function就给Username加上索引吧
======================================
已经对四个字段建立索引了，因为登录比较频繁，一直想做个这方面的缓存，可是层级太深，缓存和更新都比较麻烦。3、去除你sql里面的in
==================
以前就是采用or写法，可是SQL语句长度有限制。in写法只有or写法长度的一半多点。4、使用集群
==================
这个确实正在研究。

Answer 7

小建议：像这种id in ('1','2','5')/**1000个**/ or id in ('100','121','131')
建议把in里面的集合维护进数据库，不要写成硬编码