俺的想法：
一定要先弄清是什么地方的问题再去优化，错误的优化反而可能造成新的瓶颈；另外，不到万不得已，不要改变系统架构。

（刚才为这个主题，敲了半个小时，提交的时候报错告诉俺登录，可俺已经登录过了啊！敲的东西全丢了，实在影响心情！）

各位都是java高手，我觉得说得很有道理。不过偶补充点，这里可能需要从oracle 入手，用并行查询，在多cpu时能对大数据查询提高速度。
其它的，RAC, 分区表，优化sql，SGA调优，等等，可能需要一个整体的分析。而来的比较快的，如果是多cpu，用一个sql语句hint 就可以提高很多查询速度。

>什么时候用ejb的cache会有明显的效益?
>应该是stateful session bean或是entity bean吧?
>若是他的state的需求不是很高
>或有甚者.. 根本把logic摆在ejb中也只是一个stateless session bean
>那cache所提高的效能应该有限的吧?

ejb其实是一个pool 和cache的结合，pool用来增加会话Bean个数，保证每个线程独占一个会话bean，Cache是用来加速实体数据的。

看到大家的讨论，很精彩，都是有独到的观点。
我想说一下个人观点，数据库性能提升虽然是一个解决办法，但是它如同提高硬件性能一样，还是有限的，我们的思维应该更扩展一些。

现在大家发现，J2EE系统其实和以前的数据库系统差不多，但是为什么要用J2EE这样的中间件系统，其实说白了，就是将以前数据库做的很多事情分派到J2EE服务器来做。

因为J2EE服务器做成集群分布式比较容易，成本低，而做两台数据库集群则比较昂贵。这也是使用中间层技术的一个性能考量。

以上只是个人愚见，欢迎大家讨论。

谢谢 大家的建议.
对于starfeng朋友所说的两个改进,我在前面也是提到的
公司也有oracle的dba当时也做过深入的讨论
瓶颈无疑是在查询速度上,
虽然说几亿条数据不算大,因为以前也做过更大的系统,
但是那时逻辑关系只是主键关联,建立分区和索引就ok
而现在逻辑关系是多对多,也就是用户在数据集合中的
经纬度是不明确的,分区和索引作用也是有限,
在对sql语句的分析中,可以发现如果他的权限走的字段
和索引分区一致速度是不会导致系统暂时查询僵死的
但是还有一些时候是不走索引结果就是全表扫描.
如果要用cache机制,我想全表都要放进来,是没有意思的
同时在鉴别大操作和小操作上,没有一个明确的界限,
除非自己要检测sql的操作性能,不同的语句必须用解析器来
辨别,作为系统的编写,我们是不知道用户的权限配置组成
的语句到底大操作还是小的.

也许这么说了大家还是不明白,我就简单的把这张表的结构说一下

字段假设为
id1,id2,id3
(关联外键,不只三个,用户的权限就是这些id值不同组合,用户自己配置)
value1,value2,value3
(目标值,用户可以通过计算或不计算得出结果,要命的是要对结果排序)
有了上面的介绍,大家觉得怎么才能优化速度呢.

对不起，刚才帖子有些空洞，我想针对一个解决方案谈谈我的看法：

>一是对于用户重复点击的处理。
>二是tomcat连接池的配置。

1. 用户重复点击不应该限制，恰恰相反，使用Cache可以解决用户重复点击，因为他们反复读取的是同一个数据。

2. tomcat连接池调整幅度是有限度的，有人认为几亿次查询是小查询，我真感觉我是孤陋寡闻了，至少我是把一段时间内的几亿次查询看成是一个大访问量。

我之前提出了一个分布式Cache的解决方案，这个Cache可以自己做，使用JMS进行服务器之间通知,TSS有相关文章。

还有可以使用Jgroup，　这是JBoss集群的基础技术，因为你没有使用EJB，是裸体JavaBeans，那么就依照EJB容器底层实现，再做一次吧。

其它据我所知，没有其它更值得一试的方法了。

贴完上贴，刚看到楼主的新贴：
>字段假设为
>id1,id2,id3
>(关联外键,不只三个,用户的权限就是这些id值不同组合,用户自己配置)
>value1,value2,value3
>(目标值,用户可以通过计算或不计算得出结果,要命的是要对结果排序)

1.设定cache算法，采取LRU (Least Recently Used)算法，当然不可能对所有数据缓存了。以这三个外键为key做缓存。

2.结果排序使用Java的Collection，在内存中做，分担数据库计算。

3.在上面两步基础上，使用分布式Cache或Jgroup（或自己编制Socket），实现多台服务器缓存同步。

绝对有效，信不信由你。:)

可能我还是没有说清楚,
我开始说的选出几百条,是从排序结果中选出前几百条,它的目标集可能是千万级(依据权限来定的,一般至少是十万)
用cache,排序在内存做的话,用户一多,服务器再好也难支撑.
也许是我们这个时间和空间的平衡点还没找好.

可以再f明_一c
有哪些table
tablee面有哪些pk, fk, index
什N|西需要sort
xx

看过前面各位的帖子，觉得都说得很好，banq好像稍有些走题了
个人比较赞同startfeng的意见。

优化系统，原理其实很简单，当然做起来很难，：），就是在一
个管道上找到最窄的地方进行拓宽，搞定后再重复这个步骤。

看楼主的系统来看，500用户并发量并不是很大。又只是从数据库
取出几百条记录，可见瓶颈是在数据库了。

推荐一下：
1、分担数据库的负荷
1）如果tomcat的主机空闲，将数据库上的一部分操作挪到tomcat
上做，具体挪哪些还要看你的应用。
2）硬件条件允许的话，对oracle做RAC

2、减少对数据库的查询次数
1）做cache，，这里的cache包括两种
a、浏览器层的cache，最高效，首选。适合单用户有连续相似的操作
b、tomcat层的内存cache，高效,备选。适合单用户无连续相似的操作
，而且多用户有连续相似的操作。
以楼主项目的500用户数来看，一定要绞尽脑汁去实现 a 方法
2）引导、限制用户的不良使用习惯，“用得不怎么爽”跟“根本用不了”
如果是我肯定会选择前者

3、减少耗资源高的数据库查询操作所用的时间
1）优化sql语句，没什么可说的，找出你们效率最差的十条sql，依次
摆平。如果摆不平返回做下面的2)
2）根据应用的业务逻辑对数据库的表设计进行优化，分表是一个
比较不错的选择，你们的系统不能分，我不知道是不是因为考虑
的不够深入。

根据80/20原则，根本方法是解决成为杀手的那20%。
仅仅靠提高硬件性能是很难彻底解决问题的。

俺还是一贯立场，觉得startfeng和missxkl说得有道理。
俺的想法，原则：
1。减少不必要的数据库访问；
2。减少结果集。

想出来的一些解决办法：
1。杜绝重复点击，避免web、数据库访问的恶性循环；
2。优化sql语句，坚决不要使用复杂sql，所有的复杂sql拆分成简单的多条sql；
3。分析用户访问的可能性大小，将结果预先进行分类，建立相应的临时表（或者叫做cache表），数据库查询优先从这些表里取，若无结果，再去查原始表；
4。做其它缓存，如单用户连续访问cache、多用户相似请求的cache等等，可以借助2的结果。

其实3是文件级cache，4是内存级cache。

但不管怎样，因为俺们没有见到你的真实系统，多数还是猜想，你一定要弄清真实的瓶颈在哪里，不要优化半天，发现优化了错误的地方。

还有，可能很多人都不同意但俺自己一直坚持的，不要轻信那些看起来很美的技术，包括EJB、所谓的分布式等等，具体问题永远具体分析。

500个用户在线应该不算多，500个并发就更不大会！
我以前在网易工作，网易在解决大用户量访问和大数据量方面还是有些方法，我当时的部门负责的项目，用了7台服务器，一台主网站，主要处理用户个人信息的一些功能，有3台是主要功能服务器，3台机子用DNS做负载均衡，2台数据库，还有一台是做文件服务器的，程序方面，对于频繁需要查询的页面都是采用生成静态页面的方法，定时系统生成，虽然不能达到实时，但却减少了大量的负荷，并且，由于Apache对于静态页面的处理比Tomcat强大的太多，所以静态页面是一个很好的处理方法。另外，在数据库方面，对于大部分数据表，都采用的拆分方法，这个原理很好理解，上面的朋友也有提出，对于100条数据，如果拆分到10张表中，则每张表平均10条记录，如果拆分100张表，则单表中只有1万条记录，这种方法极大的提高了数据库的访问效率，而且DBA也比较牛，总能告诉不合理的SQL，我们都是及时修改，对于数据库中的大字段或是图片，都是采用文件保存，总的看来I/O的开销要比数据库的开销要小，我自己做的社区http://www.laoer.com:81，也是采用这样的数据库设计方式。接下来说一下应用，我们一直用Resin，连接池也是用Resin系统自带的，感觉Resin比Tomcat的性能好很多，如果用Tomcat，必将摆脱不了频繁down机的命运。我们的系统运行，正常的时候CPU一般在10%-20%，但也会出现CPU非常高的情况，这时候有一个程序会监测到CPU高的JAVA进程，然后把它kill掉，之后resin会重起。我觉得一个需要大容量用户和数据的系统，首先在数据库方面一定要设计好，能不连数据库的地方就不连数据库，表设计要完整，能在一张表查询中解决的问题，不要用多表查询或是复合查询，JAVA开发系统，本身开销就很大，如果某些地方设计不合理，性能瓶颈就很明显，另外应用的配置（Resin就可以做到一台机子同时运行几个进程，几个resin只见可以做负载均衡）、硬件等等都是因素，需要周全的考虑。

新人报到啊～～～

本猪基本同意warning第一次的意见：基本上问题的发起人还没做做基础的性能分析，大家已经在畅所欲言，有点象一帮医生，听病人说了个大概病情（譬如不能走路），就开始拿刀、拿锯了.......
So......

以前做的一个系统和你出现的情况差不多
后来发现是连接池写的有问题
对于重复点击我当时是通过提交时把页面的控键disable解决的

也许对你有帮助

1.解决并发请求的问题，http链接数要和数据库链接数匹配。个人感觉，在大访问量的情况下，情愿是限制http链接数，保证大部分人的成功操作，而不是让所有人都在等待，这样只会越来越慢。

2。防止页面刷新。

3。优化数据库，DBA的水平对数据库的性能有比较大的影响。

4。硬件。