大型网站建站要考虑：数据库压力，网页优化，服务器负载

有几个主要考虑因素：数据库压力、网页优化、服务器负载。一、1、数据库压力问题的所有压力最终都会反映在数据库上，所以我们必须对数据库有一个总体规划。数据库可根据业务、区域等特点配置，可考虑分库和使用rac、分区、分表等策略，确保数据库能够正常交易。2、您使用了两种类型的数据库，一种是SQLServer、如果一笔交易需要在两个数据库中操作，则必须考虑分布式事务。您应该仔细设计您的系统，以避免使用分布式事务，以避免更多的数据库压力和其他问题。推荐您采用延迟提交策略(不保证数据完整)，避免分布式事务问题，毕竟commit失败的概率很低。(超大系统有三套数据库，也采用延迟提交策略，避免分布式事务对数据库造成过大压力)。在应用程序前端看到你(weblogicEJB)使用F5后，我个人不太同意这个计划，虽然F5是一个很好的L4产品，但也可以基于第七层进行负载平衡和灾难容忍。然而，如果EJB采用这种方案，将不需要使用分布式事务的交易转化为分布式交易，想象一下，如果一个网络在一个请求中访问后端两个EJB，L4可能会将请求分发给不同的服务器。如果事务不保持在服务器中，则不能使用本地事务。同样，一个web，一个访问后端的请求，需要三个EJB，所以很有可能将这三个请求分发给不同的服务器，导致分布式事务。weblogic是一款很好的J2EE产品。对于这种与事务相关的负载平衡，它将优先考虑服务器中的应用程序，从而采用本地事务，提高响应速度，减少分布式事务对应用程序和数据库的压力。3、我个人认为，*件投资可能不是商业应用的主要瓶颈，而是可维护性和可扩展性是主要问题。没有必要使用不成熟的解决方案，使用更成熟的解决方案，独立使用不同的服务器进行静态和图片。对于正常的静态文件，使用E-TAG或客户缓存，许多谷歌就是这样做的。对于热点功能，考虑将其完全装载到内存中，以确保绝对响应速度。对于需要频繁访问的热点数据，采用集中缓存（多个负载均衡），以减轻数据库的压力，如大量配置信息、操作员信息等。顺便说一句，除了二进制文件外，L4上还应配置基于*件的压缩方案，以减少网络流量。提高用户对使用的感知。4、您不能要求所有用户在运营商的网络中使用镜像、多路网络接入和基于DNS的负载平衡。如果有足够的投资，可以使用CDN(内容分发网络)来减轻您的服务器压力。2、F5的负载平衡至关重要。他每秒的点击量可以达到近30万，而且它有会话的粘性。只要是同一个ip发送的请求，它就会将其分配到同一台机器，而不必担心分配错误。现在的问题是apache和tomcat的能力不平衡，动态内容压力太大，不是数据库压力。我们的数据库oracle是RAC集。性能好三，tomcat为什么会死？当时CPU或内存的占用率是多少？看看JVM占了多少？OOM有错误吗？20台tomcat不可能只支持5000并发。。。以前做过单台的resin峰值到3K都绰绰有余。。。做好缓存工作，减少动态查询4、1、F5的使用不仅可以平衡web的负载，还可以平衡基于第四层的负载。例如，大多数基于socket通信的银行接口可以在前面设置F5设备，并将请求分发给不同的服务器。F5的大部分使用都是在web层面。如果使用基于源IP地址的策略，很多客户端都是基于代理服务器的。此时，源IP地址是相同的。事实上，这些用户并没有分发到不同的服务器上。建议采用基于cookinsert的方式，采用cookie会话维护策略，loadbalance算法，需要仔细结合自己应用的实际情况来设置。2、大并发问题现在你已经得到了一个系统可以承受的大概并发，但是还是达不到系统的设计目标。这个问题应该从应用的角度来分析，web，通过工具(httplook)，检查客户端发起的请求的响应状态。如果你看到很多304请求状态，你需要优化你的url缓存，看看每个url的时间，仔细调整相对较慢的；对于tomcat或weblogic，在高并发的情况下，使用kill-3，如果这些还没有改进，就要考虑*件是否足够，配置是否合理等系统级别的问题。5.似乎瓶颈在于tomcat并发承载能力不足，但为什么tomcat只能承担200个单机并发？5、似乎瓶颈在于tomcat的并发承载能力不足，但为什么tomcat只能承担200个单机并发？当并发急剧上升时，tomcat在执行动态请求时的瓶颈在哪里？哪些程序，或者哪些链接首先导致tomcat失去响应？在davexin描述的刀片*件上，如果tomcat只运行最简单的jsp页面，500个并发页面也可以通过beajrockitJVM实现。我的猜测是瓶颈还是EJB远程调用！tomcat上的java应用程序应通过EJB远程方法调用，访问weblogic上的无状态sessionbean。这种远程方法通常在100ms~500ms级别或更多。如果没有远程调用方法，即使大量使用spring的动态反射，一个完整的web请求处理在本地JVM内部的完成时间一般只有20ms。一个web请求需要太长的执行时间，导致servlet线程占用更多的时间，无法及时响应更多的后续请求。假如这个猜测是成立的，那么我的建议就是既然你没有使用分布式事务，那就去掉EJB吧。weblogic也可以完全删除。业务层用spring代替EJB，而不是分布式架构，在每个tomcat实例上部署一个完整的分层结构。此外，在高并发条件下，apache处理静态资源也消耗内存和CPU。可以考虑使用lighttpd/CPU等轻量级webserver。litespeed/nginx取代之。6.tomcat并发低的原因很可能是remotesesionbean造成的，remotesesesionbean再次被滥用。在楼主的业务情况下，web层和service层根本不需要分开，像楼主这样的分开带来了长期的远程请求。这确实导致了tomcat上servlet资源的释放。那么remotesessionbean应该在哪里使用呢？withoutejb上写着金融系统中常用的ejb。那么remotesesionbean应该在哪里使用呢？withoutejb上写着金融系统中常用的ejb。我把他的话延伸一下，也就是说，当业务运行时间远远超过远程调用时间时，我们可以用remotesesesionbean将业务分开。而且楼主系统中没有这样的业务情况。因此，使用remotesesesionbean应该是一个错误的选择，但这个错误的选择所带来的危害被大量的*件所掩盖，导致成本的增加。而且性能不如slsb。所以我觉得改变架构最方便的方法就是用slsb去除remotesessionbean。如果用spring代替这种改造，成本相对较低。 hibernate的成本要高得多。也就是说，可以strutss Bean DAO helper，然后将weblogic作为cluster，在任何node上部署相同的应用程序。也就是说，水平扩展。理论上，当性能不符合要求时，添加node更方便。当然，即使是非农场也没关系，现在用的stick也可以分发。这种改造之所以方便，是因为很容易把remotesesionbean改成slsb，团队中的人估计对ejb比较熟悉，成本会比较低。7.最近正在做购买新*件和软件的预算。公司高层准备购买weblogic10和oracle10g，所以邀请bea公司的人员和我一起做测试。经过近几天的测试，测试了1万个并发的新系统指标，需要多少软件和*件来支持。测试了不同的组合方法，结果如下：1。1个weblogic10可支持900个用户并发(无ejb)，平均响应时间为10秒。1个weblogic10可支持900个用户并发(无ejb)，平均响应时间为10秒。一个weblogic10Express(相当于一个tomcat，用于发布jsp应用程序)和一个weblogic10(发布ejb应用程序)，可以支持1000个并发用户，平均响应时间为9秒。因为我使用的loadrunner最多支持1000个web并发，虽然weblogic此时没有错误，但是没有办法向上压。遗憾的是，我不知道最高能支持多少并发用户。3。3.一台weblogic8，可支持900个用户并发(无ejb)，平均响应时间为11秒。但没有weblogic10在同一时间内处理大量交易。weblogic10可以判断性能。4。一个tomcat4.1加一个weblogic8，只能支持350个并发用户，tomcat连接超时，说明这种结构瓶颈在tomcat。5。一台tomcat6.14加一台weblogic8，不如方案4，tomcat结超时更多，说明这种结构瓶颈在tomcat。因为tomcat6.14的调优资料还没有看到。所以也请大师给出建议。6。tomcat4.1加1weblogic10，性能也不好，问题是tomcat性能跟不上。7。tomcat6.14加1weblogic10，性能也不好，问题出现在tomcat性能跟不上。明天，我们将进行weblogic10cluster测试。有了测试结果，我们将根据每个人进行交流。上述测试机均为linuxas4操作系统，2cpu 在2G内存中，发现CPU利用率高达45%，一般在10%左右，内存可以使用1.5%G。loadruner机器2cpunnner 2G内存，windowserver2003操作系统。bea公司人员建议购买16-20cpulicens。机器购买4cpu 4-6台8G内存机。前端tomcat增加到50台。根据之前的停机记录，主要表现在tomcat层，F5也出现在个别高峰期。所以不敢轻易放弃无状态sessionbean。由于tomcat做了大部分业务，只有在需要数据库时才会调用weblogic中间件。由于weblogic的价格仍然相对昂贵，公司以前购买的weblogiclicens的数量限制。因此，所有的tomcat都不能被weblogic所取代。假如有20个weblogiclicens，我也不用担心1万个并发。八、坦白说，我从来没有听说过使用EJB进行大规模互联网应用的先例。EJB不能用于大规模互联网应用的原因，其实是因为EJB性能太差，使用EJB几乎不可避免地会出现性能障碍。阿里巴巴和淘宝是每天有多少亿PV的电商网站，其实只是JBOSS，只是用它的web容器(JBOS的web容器是tomcat)，所以本质上还是用tomcat。今年年初，RedHat在深圳的HW大客户进行了性能对比评估，JBoss4vsweblogic9在web容器评估中获胜。这个结果并不奇怪，因为web容器的性能无非是servlet的线程调度能力，tomcat不像weblogic那样附加n多管理功能，跑得快是正常的。只要你比较测试Weblogic的数据库连接池和C3P0连接池的性能，你也会发现类似的结论，C3P0比Weblogic快几倍。这并不是说Weblogic性能不好，而是说Weblogic需要实现更多的功能，所以很多东西会以单一的速度牺牲。根据我的经验，如果使用tomcat5.5以上的版本，配备apr支持，进行必要的tuning，如果使用beajrockitJVM，完全可以在你目前的刀片上支持500个并发。结合你目前20个刀片的*件，达到1万并发没问题。当然，这样做的前提是EJB必须被扔掉，web层和业务层在同一个JVM内部。从你上面的演讲来看，你之所以使用EJB，无非是因为资金有限，买不到足够的weblogiclicense。因此，退而求其次，购买少量weblogiclicense，专门运行业务层服务器，用SLSB曝光远程接口调用tomcat。然后部署n0多个免费tomcat服务