有一个J2EE项目，碰到一些性能问题。客户用LoadRunner测试，十个用户并发测试登录，就导致系统崩溃。经过检查，发现是数据池设置的太小，在IBM  WPS里面设置的数据池缺省是1-10，结果当用5个并发测试的时候，就总是有5个进程在等待数据连接。这样，系统自然通不过测试了。后来把数据池改大了，测试通过，而且速度飞快。

J2EE的性能问题，是Java诞生以来就一直存在的问题，尽管这些年间已经有了非常大的改进，但毕竟还是不如C等代码生成的程序。但我们在碰到J2EE程序性能的时候，却不能总把问题归咎于Java的问题。事实上，在很大程度上，J2EE碰到的性能问题，都是环境方面的配置问题。

简单列举一下J2EE可能碰到的性能方面的一些可能原因：
1、JVM内存分配的问题。JVM如果没有单独设置，缺省使用的内存是比较有效的，好像是32M。这样的内存，对于大并发访问是远远不够的，需要根据服务器的内存情况进行优化，这时候常常会抛内存溢出的错误。但也不能无限大，JVM最多只能使用2G的内存。比如，通常可以设置为 -Xms512m -Xmx1024m。
2、WEB服务器的并发服务线程数。通常的WEB容器都有这样一个限制，比如Tomcat缺省是75.这时候，如果使用LoadRunner等进行100用户并发测试，则肯定有不少请求会等待，而不是完全执行。WebLogic的缺省设置好像更小，我记得反正不到30.如果在实际使用中，发现这个并发线程数是瓶颈，则可以调得更大一些。
3、数据池的大小，这正好是朋友碰到的问题。通常情况下，数据池的大小，应该略大于WEB服务器的并发服务线程数。我们至少要保证每个WEB进程都能获取到相应的数据连接。如果每个WEB进程，可能需要多个数据连接，这时候数据池也应该相应调整的更大。
4、数据表的索引问题。对普通程序员，碰到性能问题的时候，很难想到表索引的问题。特别是针对大数据量的数据表，有没有合理索引的情况，查询的效率，往往是几十上百倍。建索引之前一个小时才能完成的任务，如果有合理的索引，可能1分钟不到就能搞定。索引的最简单的设置规则，就是把Where、Order子句中的所有字段都建上索引。

从以上这几个方面，往往能解决大部分的性能问题。
再来说说碰到性能问题的时候大概的思路。原则只有一个，就是“定位问题所在”。
1、查看服务器日志，日志里面的很多的有用信息，能从中初步发现问题所在。
2、结合日志，查看相应的设置，并对服务器进行监控。然后对参数进行必要的调整，继续测试。
3、如果定位到是数据库上是瓶颈，就要检查相应的数据表的索引设置。有些数据库提供SQL语句的监控和性能分析，可以分析出一些有用的结论。
以上只是一些初步的指导。如果一些初步的设置解决不了问题，则需要进一步细化了。
比如说索引的问题，简单的规则是给所有Where子句后面的字段添加索引。但这条规则太简单，某些情况下并不适用，这时候就要根据数据表的数据量、数据的差异、SQL语句等进行仔细调整。这就需要更多的经验、更仔细的调试才能得到更好的效果。
如果以上都解决不了问题，这时候就要考虑代码上是不是需要优化了。