大部门使用F5都是在web档次上，如果使用基于源IP地址的策略成都网站设计，有很多客户端都是基于代办服务器，这个时候源IP地址是一样的，实在并没有把这些用户给分发到不同的服务器上，倡议采用基于cookie insert的方法，采用cookie的会话坚持策略，loadbalance的算法，需要仔细的联合本人的应用的实际情况来设置。

如果在这些还没有改良的情况下，应该去想一想，硬件是否足够、配置是否公道等等系统级别的问题。

4。1台tomcat4.1加1台weblogic8，只能支持350个并发用户，tomcat就连结超时，阐明此种构造瓶颈在tomcat。

3。1台weblogic8， 能支持900个用户并发（没有用ejb），平均响应时间 11秒。但是没有weblogic10在同样时间内处理的交易数目多。可以断定机能不能weblogic10。

五、

三、

二、

六、

仿佛在说瓶颈在于tomcat并发承载才能不够，但为什么tomcat只能承当单机200个并发？当并发急剧回升的时候，tomcat在执举动态恳求的时候，瓶颈在哪里？是哪局部程序，或者哪个环节首先导致tomcat失去响应的？在davexin描写的刀片硬件上面，tomcat上面假如跑的仅仅是最简略的jsp页面，在采取BEA JRockit JVM的情形下，500个并发也能够到达。

看到了你在应用前端(weblogic EJB)采用了F5，我个人不是很赞成这个方案，虽然F5是一个好的L4产品，也能基于第7层做负载均衡和容灾。但是一个有事务交易的EJB，如果采用了这种方案，把不需要使用散布式事务的交易变成了分布式交易，试想，一个web如果在一个请求中，访问了后端两个EJB，那么L4就会有可能把请求分发到不同的服务器上，没有对事务保持在一个服务器中，就不能使用本地事务。同样成都网页设计，一个web，访问后端一个请求，这个请求中需要3个EJB，那么极有可能把这3个请求分发到不同的服务器，又造成了分布式事务。weblogic是一个好的J2EE产品，对这种有事务关系的负载均衡，它会优先考虑采用一个服务器里面的应用，这样就采用了本地事务，进步了响应速度，减小了分布式事务对应用和数据库的压力。

1、F5的使用 F5不光可以做web的负载均衡，也可以做基于第4层的负载均衡。 好比：银行接口，大部分基于socket通信的，就可以在前面架设一套F5装备，将请求分发到不同的服务器上。

一、

3、web的优化 我个人以为，一个贸易的应用，硬件的投资可能不是主要的瓶颈，往往可保护性，可扩大性是最主要的问题。

对了，对于简直除二进制文件，都应该在L4上配置基于硬件的紧缩方案，减少网络的流量。提高用户使用的感知。

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都更加熟习一点，成本会比较低一点

1、数据库压力问题 所有的压力终极都会反应到数据库方面，必定要对数据库有一个整体的计划。 可以依照业务、区域等等特征对数据库进行配置，可以考虑分库、使用rac、分区、分表等等策略，确保数据库能正常的进行交易。

F5的负载均衡 是必不可少的，他的每秒点击量能达到将近30万，并且它有会话的 粘性，只有是同一个ip发过来的请求，它就会把它分到统一台机器的，不必 担忧分发毛病的。当初的问题是apache和tomcat的能力不均衡，动态的内容压力太大，不是数据库的压力，咱们的数据库 oracle是RAC群集。性能很好

2、事务问题 你采用了两品种型数据库，一个SQL Server、一个oracle，如果一个交易需要在两个数据库中操作，那么必需考虑到分布式事务，你应当细心的设计你的系统，来避免使用分布式事务，以防止分布式事务带来更多的数据库压力和其它问题。推举你采用延迟提交的策略(并不保证数据的完整)，来避免分布式事务的问题，究竟commit失败的几率很低。（某个超大型体系，有3套数据库，也是采用的延迟提交策略，避免分布式事务带来的对数据库过大的压力）。

2。1台weblogic10 Express（相称于1台tomcat，用于发布jsp应用）加1台weblogic10（宣布ejb运用），能支撑1000个并发用户，均匀响应时间9秒，因为自己应用的loadRunner最多支持1000个web并发，固然此时weblogic没有任何过错，然而没措施再向上压用户，所以不晓得最高能支撑多少个并发用户，很遗憾。

tomcat上面的java利用要通过EJB远程办法调用，来拜访weblogic上面的无状况SessionBean，这样的远程方式调用个别都在100ms~500ms级别，或者更多。而如果不远程方法调用，即便大批采用spring的动态反射，一次完全的web请求处置在本地JVM内部的实现时光普通也不外20ms罢了。一次web请求须要过长的履行时间，就会导致servlet线程被占用更多的时间，从而无奈及时响应更多的后续要求。

4、网络问题 你不可能请求所有的使用职员，都跟你的服务器在一个运营商的网络内，可以考虑采用镜像、多路网络接入、基于DNS的负载平衡。如果有足够的投资，可以采用CDN(内容散发网)，减轻你的服务器压力。

tomcat为什么逝世掉？当时CPU或者内存的占用率是多少？看看其中JVM占用了多少？有没有OOM的错误？不可能20台tomcat只能支撑5000的并发。。。以前做过单台的resin峰值到3K都是绰绰有余的。。。把缓存做好，减少动态查问

如果这个推测是成立的话，那么我的提议就是既然你没有用到分布式事务，那么就罗唆去掉EJB。weblogic也可以全体撤掉，业务层使用spring取代EJB，不要搞分布式架构，在每个tomcat实例上面安排一个完整的分层结构。

七、

四、

1。1台weblogic10 能支持900个用户并发（没有用ejb），平均响应时间 10秒。

我的揣测是瓶颈仍是出在EJB远程方法调用上！

没有必要采用不成熟的方案，要更多的使用成熟的计划，将静态、图片独破使用不同的服务器，对于常态的静态文件，采用E-TAG或者客户端缓存，google良多就是这样干的。对热点的功效，考虑使用完整装载到内存，保障相对的响应速度，对于需要频繁访问的热门数据，采用集中缓存(多个可以采用负载均衡)，减轻数据库的压力，比方：许多配相信息，操作员信息等等。

近段时间正在做购置新硬件和新软件的估算，公司高层筹备买weblogic10和oracle 10g，所以请了bea公司的人员和我一块做测试，经由近几天的测试，测试一下新的系统指标1万个并发，需要多少软件和多少硬件可能支撑，已经测试了不同的组合方式，有了不同的成果，分辨如下：

另外在高并发情况下，apache处理静态资源也很耗内存和CPU，可以考虑用轻量级web server如lighttpd/litespeed/nginx代替之。

2、大并发的问题 现在你得到了一个大略的系统能蒙受的并发，但是还达不到系统的设计目的。 应该从应用的角度去剖析这个问题，web方面，通过工具(httplook)，检讨一下客户端发动的请求都是什么响应状态，如果看到很多304请求状态，你需要优化你的url缓存，看一下每个url的消耗时间，仔细针对比拟慢的进行调优；对于tomcat或者weblogic，在高并发的情况下，用kill -3 <PID>，取得ThreadDump(HeapDump需要特别的设置)，看一下在高并发下，jvm的线程到底在干什么，仔细的分析可能对你有辅助。