一定要先弄清是什么地方的问题再去优化，错误的优化反而可能造成新的瓶颈；另外，不到万不得已，不要改变系统架构。
（刚才为这个主题，敲了半个小时，提交的时候报错告诉俺登录，可俺已经登录过了啊！敲的东西全丢了，实在影响心情！）
一定要先弄清是什么地方的问题再去优化，错误的优化反而可能造成新的瓶颈；另外，不到万不得已，不要改变系统架构。
一定要先弄清是什么地方的问题再去优化，错误的优化反而可能造成新的瓶颈；另外，不到万不得已，不要改变系统架构。
其它的，RAC, 分区表，优化sql，SGA调优，等等，可能需要一个整体的分析。而来的比较快的，如果是多cpu，用一个sql语句hint 就可以提高很多查询速度。
>应该是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,排序在内存做的话,用户一多,服务器再好也难支撑.
也许是我们这个时间和空间的平衡点还没找好.
有哪些table
tablee面有哪些pk, fk, index
什N|西需要sort
xx
个人比较赞同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%。
仅仅靠提高硬件性能是很难彻底解决问题的。
俺的想法，原则：
1。减少不必要的数据库访问；
2。减少结果集。
想出来的一些解决办法：
1。杜绝重复点击，避免web、数据库访问的恶性循环；
2。优化sql语句，坚决不要使用复杂sql，所有的复杂sql拆分成简单的多条sql；
3。分析用户访问的可能性大小，将结果预先进行分类，建立相应的临时表（或者叫做cache表），数据库查询优先从这些表里取，若无结果，再去查原始表；
4。做其它缓存，如单用户连续访问cache、多用户相似请求的cache等等，可以借助2的结果。
其实3是文件级cache，4是内存级cache。
但不管怎样，因为俺们没有见到你的真实系统，多数还是猜想，你一定要弄清真实的瓶颈在哪里，不要优化半天，发现优化了错误的地方。
还有，可能很多人都不同意但俺自己一直坚持的，不要轻信那些看起来很美的技术，包括EJB、所谓的分布式等等，具体问题永远具体分析。
我以前在网易工作，网易在解决大用户量访问和大数据量方面还是有些方法，我当时的部门负责的项目，用了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解决的
也许对你有帮助
2。防止页面刷新。
3。优化数据库，DBA的水平对数据库的性能有比较大的影响。
4。硬件。