wjgo 2004-03-18 15:04
Tomcat 4 的并发性本来就是很差的，压力测试在300以上就达到极限了，还是移植到其他平台吧
Jevang 2004-03-19 01:33
To the case owner: before you claim that you have done enough to optimised the database, show us some tkprof statistics, under single user and multiple users load.

A minor question: assume there are 500 records qualified for the search criteria, will user have to get all of them at once, all they just need to see the first portion of it?

"Starfeng" made very good points about tuning. I was involved in a 1,600 concurrent user system 2 years back, though our implmentation is not exact the same, performance bottleneck areas are identical.

Cheers,
-Jevang

woodqiang 2004-03-19 11:47
tomcat没响应我觉得是由于tomcat中用于响应请求的线程都用光了.这时应该是连静态页面都不能访问的.为什么用光了.应该就是你的那些大查询都不能及时返回,所以用于做大查询的线程都停在那里了,而你又有新的请求进来.就没线程来响应这些请求了.以前我在weblogic中也试过这些的情况，weblogic里面有个＂处理线程数＂的参数默认为１５．如查当前的线程数过了１５．整个服务就不动了，而且那１５个线程也不释放了．不知道是不是它的bug?后台把这个数改大就没事了．但这个参数对应用服务器的性能有效大影响．所以不要设得过大．估计tomcat也有差不多的设置.
查询慢的话可以看一下connection的设置，我听同事说可以一次返回多条结果集的查询．可以大大提高查询返回的速度．可能有一点帮助吧．不过你的瓶颈不在这．
evan 2004-03-24 10:30
我的两个建议：
1.检查java程序，看ResultSet,Statement和Connection是否都及时关闭、释放。

在使用连接池的情况下，尤其要保证在关闭Connection前确实关闭了ResultSet和Statement。因为实际上Connection并没有关闭只是释放到pool中，如果statement未关闭则相应的数据库cursor也不能及时释放

2.使用oracle物化视图

物化视图是包括一个查询结果的数据库对像，它是远程数据的的本地副本，或者用来生成基于数据表求和的汇总表。物化视图存储基于远程表的数据，也可以称为快照。对大数据量、多表连接的查询效果很好

也可以建立临时表来缓存多表连接查询的结果，以后的查询只需要基于此临时表即可。这种方法需要修改查询的流程：第一步是聚集数据（粗条件查询，如查询条件只有开始、结束时间或只有分支机构），第二步是细化查询（基于临时表操作）

zhuam 2004-03-29 13:30
-- 此榈谝「M主C」：www.example.com
　　Host name="www.example.com" appBase="/home/example/webapp"
　　 Context path="" docBase="."/
　　/Host
　　　
凤舞凰扬 2004-04-01 23:24
楼上，也是太威猛了吧？？我做了三年多J2EE应用，还没有碰到过几亿条的数据（包括财务、审计，还是国家级的，都没有见过），直接这么访问，说实话用什么都不行的，因为你的数据库设计绝对是个败笔！
没有想到，居然还只是用javabean来写，太夸张了！！！
youngS 2004-04-03 01:41
看了这么多，觉得很多人的建议都有些道理，我也有些想法，要是大家有意见，请扔西红柿，抗议使用石头和西瓜皮。另：java我是新手，C/C++倒是一直在捣鼓，不过我相信除了语法不同，很作运作原理都是一样的。最近一直在看java，希望能早点融会贯通。

1。使用cache
cache的本意是减少I/O操作，因为I/O操作非常的费时，但是cache的设计应该使命中率提高才有实际意义。cache设计出来之后，个人的理解是最好创建一个线程（或其他更系统的方法）监视数据库，如果有变动，可以及时更新到cache中，不用等请求来了再手忙脚乱的玩cache。为了解决cache快照之类的问题，也许可以采用双缓冲，轮流上阵（设想中。。。）。照一楼的描述来看，虽说数据量大，但是如果数据库的插入和更新操作不是那么频繁的话，我觉得cache确实还是很有意义的。

2。http连接数控制
连接数不要那么大，把连接数改那么大并不是一种好想法。连接数增大的目的是使前端的响应看起来快一点（只是看起来快一点而已，实际上对单个客户端来说处理速度更慢，响应速度和处理速度不是同一回事）。当连接池的线程都忙于处理时请求接收线程应该向前端返回一个服务器忙的友好信息，而不是傻傻的停在哪里。

3。线程的问题
java线程如果是用户级线程，当某个线程中使用阻塞调用时，整个系统都将停顿（好像死掉了一样），不过看来java线程好像没有这个问题。

4。数据库设计问题
数据库设计的问题不能光从性能上考虑而忽略了合理的设计，数据库的设计仍然应该按照面向对象的思想来分析。好的数据库设计可以省去应用层复杂的算法，因为一个复杂的、差的算法带来的性能损失也相当惊人，且系统易产生不稳定的现象。至于分不分表，应以分析结果为准。

5。分布式数据库的问题
分布式数据库的目的其实是为了分散I/O操作压力，把一定时间内的所有的I/O操作分散到几个物理服务器上，相当于提高了单位时间内的I/O吞吐量，性能当然会提高。但是这里面要考虑一个问题，即数据库的数据分布也应该具备分布式的特性，因为虽然数据库分布式了，可是大量经常查询的数据还是集中在其中的某一台物理服务器上，这分布式就算是白做了。为了达到数据呈分布式特征，就需要对数据的特征做一些设计，然后在应用层根据请求的数据特征把请求发送到某台具有这一数据特征的数据库服务器上。如果这些特征能在服务器上按哈希分布，其查询性能我觉得应该会比较高。

解决方法建议按上述思路思考。

youngS 2004-04-03 01:50
我印象里java的内存释放时机好像是可以控制的，如果不怕麻烦，最好在这方面关注一下。

pacor 2004-04-13 09:23
使用第三方商业全文数据库工具
kdyi 2004-04-15 23:49
总算看到尾，感觉youngS总结的大概正确
楼主也说过更多数据以前也处理过
我只想说一点：
SQL SORT
不要搞太复杂的算法，象数据挖掘就坏了
结果集太分散
几亿条数据，再怎么搞，也不够败家
liloboy 2004-04-25 01:34
1.数据库的问题大于java所能够解决的问题.
a.估计一下数据的实际的两有多大,100G+? need cluster index?
2.解决问题之前先看看到底瓶颈在哪里.
a.比如Unix上面的top,windows上面的filemon
b.oracle的优化上面,索引的问题到底怎样?是否有更好的办法去得到数据而不是乱用join.
3.用loadrunner测试一下
4.是否有OLTP和DSS的基本概念,如果有的话
5.问题解决的成本很高,所以,动手之前先推理一下,看看有什么疑点,列一下成本/受益看看合不合算.
mark_wyh 2004-05-16 10:02
还是用catch，把大量的查询分成几个catch
wjsir 2004-05-17 14:50
楼主上亿条的数据、500的并发，居然用tomcat，这是什么客户这么抠门阿
fiddle 2004-05-26 11:00
和别的都没有关系，只是数据库瓶颈。在上亿条记录中去group by和order by，普通设备很难顶得住并发，几个并发就彻底慢下来了

解决建议
1、拆分表，使你操作的数据集尽量的小
2、建立中间表，对于统计类信息查询中间表，定时生成中间表
3、做数据库的负载均衡