其中主要考虑的方面有几点：数据库压力，网页优化，服务器负载。
一、
1、数据库压力问题 所有的压力最终都会反映到数据库方面，一定要对数据库有一个整体的规划。 可以按照业务、区域等等特性对数据库进行配置，可以考虑分库、使用rac、分区、分表等等策略，确保数据库能正常的进行交易。
2、事务问题 你采用了两种类型数据库，一个SQL Server、一个oracle，如果一个交易需要在两个数据库中操作，那么必须考虑到分布式事务，你应该仔细的设计你的系统，来避免使用分布式事务，以避免分布式事务带来更多的数据库压力和其它问题。推荐你采用延迟提交的策略(并不保证数据的完整)，来避免分布式事务的问题，毕竟commit失败的几率很低。（某个超大型系统，有3套数据库，也是采用的延迟提交策略，避免分布式事务带来的对数据库过大的压力）。
看到了你在应用前端(weblogic EJB)采用了F5，我个人不是很赞同这个方案，虽然F5是一个好的L4产品，也能基于第7层做负载均衡和容灾。但是一个有事务交易的EJB，如果采用了这种方案，把不需要使用分布式事务的交易变成了分布式交易，试想，一个web如果在一个请求中，访问了后端两个EJB，那么L4就会有可能把请求分发到不同的服务器上，没有对事务维持在一个服务器中，就不能使用本地事务。同样，一个web，访问后端一个请求，这个请求中需要3个EJB，那么极有可能把这3个请求分发到不同的服务器，又造成了分布式事务。weblogic是一个好的J2EE产品，对这种有事务关联的负载均衡，它会优先考虑采用一个服务器里面的应用，这样就采用了本地事务，提高了响应速度，减小了分布式事务对应用和数据库的压力。
3、web的优化 我个人认为，一个商业的应用，硬件的投资可能不是主要的瓶颈，往往可维护性，可扩展性是最主要的问题。
没有必要采用不成熟的方案，要更多的使用成熟的方案，将静态、图片独立使用不同的服务器，对于常态的静态文件，采用E-TAG或者客户端缓存，google很多就是这样干的。对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存(多个可以采用负载均衡)，减轻数据库的压力，比如：很多配置信息，操作员信息等等。
对了，对于几乎除二进制文件，都应该在L4上配置基于硬件的压缩方案，减少网络的流量。提高用户使用的感知。
4、网络问题 你不可能要求所有的使用人员，都和你的服务器在一个运营商的网络内，可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。如果有足够的投资，可以采用CDN(内容分发网)，减轻你的服务器压力。
二、
F5的负载均衡 是必不可少的，他的每秒点击量能达到将近30万，并且它有会话的 粘性，只要是同一个ip发过来的请求，它就会把它分到同一台机器的，不用 担心分发错误的。现在的问题是apache和tomcat的能力不平衡，动态的内容压力太大，不是数据库的压力，我们的数据库 oracle是RAC群集。性能很好
三、
tomcat为什么死掉？当时CPU或者内存的占用率是多少？看看其中JVM占用了多少？有没有OOM的错误？不可能20台tomcat只能支撑5000的并发。。。以前做过单台的resin峰值到3K都是绰绰有余的。。。把缓存做好，减少动态查询
四、
1、F5的使用 F5不光可以做web的负载均衡，也可以做基于第4层的负载均衡。 比如：银行接口，大部分基于socket通讯的，就可以在前面架设一套F5设备，将请求分发到不同的服务器上。
大部分使用F5都是在web层次上，如果使用基于源IP地址的策略，有很多客户端都是基于代理服务器，这个时候源IP地址是一样的，其实并没有把这些用户给分发到不同的服务器上，建议采用基于cookie insert的方式，采用cookie的会话保持策略，loadbalance的算法，需要仔细的结合自己的应用的实际情况来设置。
2、大并发的问题 现在你得到了一个大概的系统能承受的并发，但是还达不到系统的设计目标。 应该从应用的角度去分析这个问题，web方面，通过工具(httplook)，检查一下客户端发起的请求都是什么响应状态，如果看到很多304请求状态，你需要优化你的url缓存，看一下每个url的耗费时间，仔细针对比较慢的进行调优；对于tomcat或者weblogic，在高并发的情况下，用kill -3 PID>，获得ThreadDump(HeapDump需要特殊的设置)，看一下在高并发下，jvm的线程到底在干什么，仔细的分析可能对你有帮助。
如果在这些还没有改善的情况下，应当去想一想，硬件是否足够、配置是否合理等等系统级别的问题。
五、
似乎在说瓶颈在于tomcat并发承载能力不够，但为什么tomcat只能承担单机200个并发？当并发急剧上升的时候，tomcat在执行动态请求的时候，瓶颈在哪里？是哪部分程序，或者哪个环节首先导致tomcat失去响应的？在davexin描述的刀片硬件上面，tomcat上面如果跑的仅仅是最简单的jsp页面，在采用BEA JRockit JVM的情况下，500个并发也可以达到。
我的推测是瓶颈还是出在EJB远程方法调用上！
tomcat上面的java应用要通过EJB远程方法调用，来访问weblogic上面的无状态SessionBean，这样的远程方法调用一般都在100ms~500ms级别，或者更多。而如果没有远程方法调用，即使大量采用spring的动态反射，一次完整的web请求处理在本地JVM内部的完成时间一般也不过20ms而已。一次web请求需要过长的执行时间，就会导致servlet线程被占用更多的时间，从而无法及时响应更多的后续请求。
如果这个推测是成立的话，那么我的建议就是既然你没有用到分布式事务，那么就干脆去掉EJB。weblogic也可以全部撤掉，业务层使用spring取代EJB，不要搞分布式架构，在每个tomcat实例上面部署一个完整的分层结构。
另外在高并发情况下，apache处理静态资源也很耗内存和CPU，可以考虑用轻量级web server如lighttpd/litespeed/nginx取代之。
六、
tomcat之所以并发低很可能是由于remote session bean造成的，remote session bean又一次被滥用了，在楼主的这种业务情况下，web层和service层根本不需要分开，象楼主这样分开带来就是一访问业务层就带来长时间的远程请求，确实导致tomcat上servlet资源释放的问题。那么remote session bean应该被用在什么地方呢，without ejb上有写到金融系统常用ejb。我把他的这句话延伸一下，也就是说当业务的运行时间远超过远程调用的时间时，我们就可以用remote session bean来把这个业务分离出去。而楼主的系统中没有这种业务情况。所以使用remote session bean应该来说是一个错误的选择，不过这个错误的选择带来的危害被大量的硬件所掩盖，带来的是成本的提高。而性能上还不如slsb。
所以我觉得如果要改架构最便捷的方法是使用slsb，把remote session bean去掉。这样改造的成本比较低，如果换成spring+hibernate成本就高得多了。也就是说可以struts+Bean+DAO+helper，然后把weblogic作cluster，任意一个node上都部署相同的应用。也就是水平扩展，理论上来讲当性能不满足要求时添加node就行了，如果能做成农场就更加方便了。当然即使非农场也没有关系，可以用现在在使用的stick分发。这样的改造之所以方便是因为把remote session bean改成slsb是很容易的，而且团队里的人估计对ejb都更加熟悉一点，成本会比较低一点
七、
近段时间正在做购买新硬件和新软件的预算，公司高层准备买weblogic10和oracle 10g，所以请了bea公司的人员和我一块做测试，经过近几天的测试，测试一下新的系统指标1万个并发，需要多少软件和多少硬件能够支撑，已经测试了不同的组合方式，有了不同的结果，分别如下：
1。1台weblogic10 能支持900个用户并发（没有用ejb），平均响应时间 10秒。
2。1台weblogic10 Express（相当于1台tomcat，用于发布jsp应用）加1台weblogic10（发布ejb应用），能支持1000个并发用户，平均响应时间9秒，由于本人使用的loadRunner最多支持1000个web并发，虽然此时weblogic没有任何错误，但是没办法再向上压用户，所以不知道最高能支撑多少个并发用户，很遗憾。
3。1台weblogic8， 能支持900个用户并发（没有用ejb），平均响应时间 11秒。但是没有weblogic10在同样时间内处理的交易数量多。可以判定性能不能weblogic10。
4。1台tomcat4.1加1台weblogic8，只能支持350个并发用户，tomcat就连结超时，说明此种结构瓶颈在tomcat。
5。1台tomcat6.14加1台weblogic8，还不如方案4，tomcat结超时更多，说明此种结构瓶颈在tomcat。由于还没有看tomcat6.14的调优资料。所以还请高手给建议。
6。1台tomcat4.1加1台weblogic10，性能同样不佳，问题出现在tomcat性能跟不上。
7。1台tomcat6.14加1台weblogic10，性能同样不佳，问题出现在tomcat性能跟不上。
明天还要做一个weblogic10 cluster测试，等有了测试结果，再根大家交流。
以上测试机器都为 linux as4 操作系统，2cpu + 2G内存，发现cpu利用率最高占45%，一般就在10%左右，内存可以用到1.5G。 loadRunner机器为2cpu + 2G内存，window server 2003操作系统。
有以上的结果，bea公司人员建议购买16-20cpu的licens。机器购买4cpu + 8G内存机器4-6台。前端tomcat增加到50台。
由于根据以前的宕机记录，主要表现在tomcat层，个别高峰时候也出现在F5。故不敢轻易的舍弃无状态session bean。由于tomcat做了大部分的业务，只有需要数据库的时候才调用weblogic中间件，由于weblogic的价格还是比较昂贵的，公司以前购买的weblogic licens数量限制。所以还不能把所有的tomcat换成weblogic。如果有20台weblogic的licens，我也就不担心1万个并发了。
八、
坦白说我还从来没有听说过大规模互联网应用使用EJB的先例。为什么大规模互联网应用不能用EJB，其实就是因为EJB性能太差，用了EJB几乎必然出现性能障碍。阿里巴巴和淘宝网那是每天多少亿PV的电子商务网站了，其实也就是用JBoss而已，而且也只是用其web容器(JBoss的web容器就是tomcat)，所以本质上还是在用tomcat。
今年年初，RedHat在深圳的HW大客户在内部做过性能对比评测，JBoss4 vs WebLogic 9，在web容器一项的评测当中，JBoss4胜出。这个结果并不令人感到意外，因为web容器的性能说到底无非就是Servlet线程调度能力而已，Tomcat不像WebLogic那样附加n多管理功能，跑得快很正常。这一点你只要对比测试一下WebLogic的数据库连接池和C3P0连接池的性能也会发现类似的结论，C3P0可要比WebLogic的连接池快好几倍了。这不是说WebLogic性能不好，只不过weblogic要实现更多的功能，所以在单一的速度方面就会牺牲很多东西。
以我的经验来判断，使用tomcat5.5以上的版本，配置apr支持，进行必要的tuning，使用BEA JRockit JVM的话，在你们目前的刀片上面，支撑500个并发完全是可以做到的。结合你们目前20个刀片的硬件，那么达到1万并发是没问题的。当然这样做的前提是必须扔掉EJB，并置web层和业务层在同一个JVM内部。
从你上面的发言来看，你们之所以采用EJB，无非是因为经费有限，无法购买充足的weblogic license。所以退而求其次，购买少量的weblogic license，专门跑业务层服务器，用SLSB暴露远程接口给tomcat调用。然后部署n十多台免费的tomcat服务器跑web。为省钱而采用EJB到是一个很新鲜的事，但实际上这就是一个很愚蠢的决定。
weblogic的优秀更多的体现在他对于J2EE标准优秀的支持，各种复杂的企业应用场景以及传统的中间件应用的丰富而方便的集成手段上。简单的来说，就是weblogic/websphere是企业应用的首选，特别是强调事务的企业应用，例如金融，电信计费。但在互联网应用方面，weblogic/websphere根本就体现不出有什么能够超过resin/tomcat的地方，诚然weblogic express的web容器稳定性要好于tomcat，但没有互联网企业在大规模部署tomcat水平群集的时候，还会为这一点而疯狂买单购买weblogic license。
所以我个人很不理解，作为一个互联网公司的CTO，怎么会如此迷信weblogic，因为我认识的互联网公司高层，没有什么人愿意用商业产品，绝大多数都是用开源的，我不惮揣测他的背景可能来自传统企业应用出身的吧，呵呵。
九、
这说明瓶颈还不在EJB远程调用上，但是问题已经逐渐清楚了。为什么weblogic充当web容器发起远程EJB调用的时候可以支撑1000个并发，但是tomcat只能到350个？只有两个可能的原因：
1、你的tomcat没有配置好，严重影响了性能表现 2、tomcat和weblogic之间的接口出了问题
上面的帖子其实我也介绍过了，如果只是单纯的作为servlet容器来看，tomcat的性能不应该比weblogic差，甚至还要更好，所以你可以这样来拟定测试方案：
在同样硬件环境下对比测试tomcat5.5和weblogic10的servlet容器性能，分别写几个访问数据库，和不访问数据库的JSP页面测试就可以了，并发从500往上走，看看哪个throughput更高。记得要调优tomcat5.5，配置apr支持要打开。
如果测试结果表明tomcat并发响应能力远远差于weblogic，那就说明你的tomcat配置有很大的问题，好好钻研tomcat configuration performance tuning吧；
如果测试结果表明tomcat并发响应能力与weblogic相当，或者差不多，那么很不幸，问题不在tomcat本身，而是出在了tomcat到weblogic的接口上。而tomcat是通过weblogic提供的EJB client jar去调用weblogic的EJB的，那你只好咨询BEA去寻求解决方案了。
十、
1.基础配置优化 tomcat 6？ tomcat参数调优? JRockit JVM? JVM参数调优？ Apache+Squid 处理静态内容？
2.业务层优化 部分功能本地化，而不调remote session bean? 异步提交操作,JMS？ cache热点数据？
3.展示层优化 动态页面发布为静态页面？ Cache部分动态页面内容？
十一、
对于楼主的问题，以及公司的架构方案，我认为你们仍然在犯错！ 误区：遇到性能问题的第一件事情就是找硬件和容器的事情! 性能问题的基本上无一例外的都出在写的程序有问题，满足不了伸缩性。 好好看看你们的程序吧，不要再给bea打电话了，你得到的建议，基本上都是用不到的。 robin的观点是对的，我甚至怀疑你们的数据库连接是否有释放问题的。 增加你们前端的内存，多做缓存。hibernate的cache方案不差jdbc对数据库的频繁使用 html的书写是否符合w3的规范
最好在一个服务器上部署整个应用！
十二、
淘宝用的weblogic8,他们的web层使用的Turbine，且大量的使用velocity，由于对事务要求及其苛刻用到了ejb,也用到spring很多其他服务，访问数据库使用ibatis，他们对weblogic优化到的极致加上外面也架了apache,，在如此高并发的情况，且高度复杂的搜索。。。，还能保持如此的响应速度，确实很不错。
淘宝的搜索功能说是在的非常强大，不晓得是不是yahoo中国来人做的，一直觉得很神奇
robbin大哥说的还是很有道理，对于大多数门户门户网站，使用EJB确实浪费，购买weblogic的钱可以购买很多硬件来apache,tomcat负载均衡远远胜过于ejb方案的性能。没有绝对的性能好坏之分，主要还是看你的需求，weblogic永远是对于银行，证券，电信的行业所准备，他们所使用的硬件对象也绝对不是刀片，双路至强的硬件这样的东东。
十三、
经过今天修改tomcat的参数，修改如下： Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="8080" enableLookups="false" redirectPort="8443" acceptCount="500" maxProcessors="500" minProcessors="500" maxSpareProcessors="200" connectionTimeout="20000" useURIValidationHack="false" disableUploadTimeout="true" /> 经过测试，并发人数是可以达到像robbin所说的一样，能够在600人左右，如果压到并发700人，就有15%左右的失败，虽然在调整上面参数之后，并发人数上去了，但是在同样的时间内所完成的事务数量下降了10%左右，并且响应时间延迟了1秒左右，但从整体上来说，牺牲一点事务吞吐量和响应时间，并发人数能够提高500，觉得还是值得的。谢谢robbin的建议。
由于本人使用的loadRunner 能支持的独立client数量在100个，所以没办法对ejb进行单独的压力测试。因为我在对前段应用调用ejb时，最多并发用户已经达到1000个，但是通过监控weblogic10中发布的ejb应用和连接池，发现ejb应用等待数量为0，但是连接池中最多有60个活动连接，有7个连接在等待，因为此时设置的weblogic连接池最大数量是60，后来对连接池数量进行增大到160个，再次进行测试，发现性能反而不如把连接池数量调为60个的时候。问起bea的人，他们也说不清楚原因。
同时对他们所提供的一种更好的jvm进行测试，jvm的名字是 RealTime.发现性能并没有太大改善。 我们现在的系统已经作了很多的缓存，有全局的，有局部的，都是放到内存中的HashMap，静态的页面都是放在apache上的，不过没有使用 apr， 接下来如果有时间，会测试一下这个咚咚。
che前面是F5负载均衡器，在apache后面是tomcat，tomcat在公网上，然后通过内网网卡访问weblogic，weblogic才能访问数据库，tomcat不能直接访问数据库的，由于以前的网络结构的原因，也有安全的原因，公司还有部分服务器在北京（无线事业部）和广州（老系统，以后会逐渐迁移到上海），虽然现在也有其他的安全方案可以把tomcat放在内网，去掉weblogic，但是这种改变是需要时间的，也要考虑平稳过渡，所以还请各位理解。至于购买weblogic，公司也是有自己的考虑的。因为以前就是运行在weblogic上的，如果现在不用了，如果出了问题，就很难办了。
十四、
是的，如果调整参数，可以达到并发人数达到1000以上，但是通过对比同样压力下的weblogic和tomcat，发现tomcat的响应时间都比weblogic长，并且tomcat的cpu的占用率达到45%-60%，而同样的压力下weblogic的cpu占用只有3%-5%。内存都是2G都用了97%，说明主要差别表现在cpu和相应时间上，我没有做tomcat 1000人并发测试，但是从以前600人并发的响应时间判断，我觉得响应时间可能会超过15秒。所以从综合各方面性能指标考虑，我觉得要找出一个响应时间，并发人数，完成交易数量3方面考虑折中，找出一个满足应用响应时间和并发用户的折中吧，如果是并发交易量比较大的应用，我想应该减少并发用户，提高单位时间内交易数量来满足应用需求吧。
十五、
又回到了realtime的定义，并不是很快的意思，而是响应时间是可预计的。
而JVM对响应时间可预计性的影响，主要表现在 1.线程调度受操作系统线程调度的影响 2.垃圾收集引起的暂停
所以jrockit选择了动态垃圾收集，以频繁的收集来换取每次中断时间的减少，所以，对吞吐量来说，是反而会下降的。大部分jvm都有吞吐量优先，短暂停时间两种截然不同的垃圾收集算法。
