网站开发 系统架构 项目管理 策划运营 行业趋势 团队组建 创业 吴玉启

　将静态、图片独立使用不同的服务器，对于常态的静态文件，采用E-TAG或者客户端缓存， google很多就是这样干的。对于热点的功能，考虑使用完全装载到内存，保证绝对的响应速度，对于需要频繁访问的热点数据，采用集中缓存(多个可以采用负载均衡)，减轻数据库的压力。
　　对于几乎除二进制文件，都应该在L4上配置基于硬件的压缩方案，减少网络的流量。提高用户使用的感知。
　　网络问题
　　可以考虑采用镜像、多路网络接入、基于DNS的负载均衡。如果有足够的投资，可以采用CDN(内容分发网)，减轻你的服务器压力。
　　cauherk的这个分析比较到位，其中ETags的方案是最近的一个热点，InfoQ的“使用ETags减少Web应用带宽和负载”里面对这种方案有很详细的介绍。一般以数据库为中心的Web应用的性能瓶颈都在数据库上，所以cauherk把数据库和事务问题放到了前两位来讨论。但是davexin解释在所讨论的这个项目中数据库并非瓶颈：
　　我们的压力不在数据库层，在web层和F5。 当高峰的时候 ，F5也被点死了，就是每秒点击超过30万，web动态部分根本承受不了。根据我们程序记录，20台web最多承受5000个并发，如果再多，tomcat就不响应了。就像死了一样。
　　这个回复让接下来的讨论都集中于Web容器的性能优化，但是JavaEye站长robbin发表了自己的意见，将话题引回了这个项目的架构本身：
　　performance tuning最重要的就是定位瓶颈在哪里，以及瓶颈是怎么产生的。
　　我的推测是瓶颈还是出在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取代之。
　　robbin的推断得到了网友们的支持，davexin也认同robbin的看法，但是他解释说公司认为放弃SLSB存在风险，所以公司倾向于通过将Tomcat替换为Weblogic Server 10来提升系统的用户支撑能力。robbin则马上批评了这种做法：
　　坦白说我还从来没有听说过大规模互联网应用使用EJB的先例。为什么大规模互联网应用不能用EJB，其实就是因为EJB性能太差，用了EJB几乎必然出现性能障碍。
　　web容器的性能说到底无非就是Servlet线程调度能力而已，Tomcat不像WebLogic那样附加n多管理功能，跑得快很正常。对比测试一下WebLogic的数据库连接池和C3P0连接池的性能也会发现类似的结论，C3P0可要比WebLogic的连接池快好几倍了。这不是说WebLogic性能不好，只不过weblogic要实现更多的功能，所以在单一的速度方面就会牺牲很多东西。
　　以我的经验来判断，使用tomcat5.5以上的版本，配置apr支持，进行必要的tuning，使用BEA JRockit JVM的话，在你们目前的刀片上面，支撑500个并发完全是可以做到的。结合你们目前20个刀片的硬件，那么达到1万并发是没问题的。当然这样做的前提是必须扔掉EJB，并置web层和业务层在同一个JVM内部。
　　接下来robbin还针对davexin对话题中的应用分别在tomcat和weblogic上的测试数据进行了分析：
　　引用：
　　2。1台weblogic10 Express（相当于1台tomcat，用于发布jsp应用）加1台weblogic10（发布ejb应用），能支持1000个并发用户……
　　……
　　4。1台tomcat4.1加1台weblogic8，只能支持350个并发用户，tomcat就连结超时，说明此种结构瓶颈在tomcat。
　　这说明瓶颈还不在EJB远程调用上，但是问题已经逐渐清楚了。为什么weblogic充当web容器发起远程EJB调用的时候可以支撑1000个并发，但是tomcat只能到350个？只有两个可能的原因：
　　你的tomcat没有配置好，严重影响了性能表现
　　tomcat和weblogic之间的接口出了问题
　　接着springside项目发起者江南白衣也提出了一个总体的优化指导：
　　1.基础配置优化
　　tomcat 6？ tomcat参数调优?
　　JRockit JVM? JVM参数调优？
　　Apache+Squid 处理静态内容？
　　2.业务层优化
　　部分功能本地化，而不调remote session bean?
　　异步提交操作,JMS？
　　cache热点数据？
　　3.展示层优化
　　动态页面发布为静态页面？
　　Cache部分动态页面内容？
　　davexin在调整了Tomcat配置后应验了robbin对tomcat配置问题的质疑，davexin这样描述经过配置优化以后的测试结果：
　　经过测试，并发人数是可以达到像robbin所说的一样，能够在600人左右，如果压到并发700人，就有15%左右的失败，虽然在调整上面参数之后，并发人数上去了，但是在同样的时间内所完成的事务数量下降了10%左右，并且响应时间延迟了1秒左右，但从整体上来说，牺牲一点事务吞吐量和响应时间，并发人数能够提高500，觉得还是值得的。
　　至此这个话题有了一个比较好的结果。这个话题并非完全针对一个具体的项目才有意义，更重要的是在分析和讨论问题的过程中网友们解决问题的思路，尤其是cauherk、robbin、江南白衣等几位网友提出的意见可以让广大Java Web项目开发者了解到中、大型项目所需要考虑的架构和部署所需要考虑的关键问题，也消除了很多人对轻量Servlet容器与EJB容器性能的一些误解。

地方网站编辑绩效考核的历史，就是编辑们被误导被曲解被压迫的历史，也是网站管理者妄想迷失与失望的历史。许多时候，绩效考核被当做业绩的春药引入，最后被证实为毒药。最后，引发了管理者的反思，才真正意识到绩效考核的真实含义。

以深度报道全球生态环保问题而著称的美国著名杂志《母亲琼斯》（MotherJones），最近刊登了一篇题为《超越保护主义》的文章，文中的农场主乔尔·塞拉廷养的家禽与种的蔬菜只卖给附近的居民，并拒绝以条形码方式进入超市

SNS+电子商务，电子商务发展的必然趋势，也是SNS网站走出盈利难的一条捷径，目前淘宝的淘江湖等应用已经火热，但还没有达到在线社交电子商务所应该能达到的需求，淘宝推出淘江湖更多的也许只是为了防止SNS网站进入电子商务领域打的一场防守战，京东商城、当当网、买包包、麦考林等也许都在筹划自己的SNS系统，但这些日新月异的新产品上市速度、必然影响相应的在线社交的设计。对这一点我将继续深究，下面是一片转载博文，读完很有收获，推荐给大家一阅。

对于商业网站来说，如何加强社会化功能是一个很纠结的问题。如果做的适当，将会更进一步理顺交易流程，大大增强用户好的体验，赢得更多订单。但绝大多数网站却都是机械的加入一些社会化功能，甚至把加入社会化功能做为一种标准配置，而丝毫不去考虑用户是否真正需要。这样的失败案例或者做无用功的案例现在已经变得举目皆是。Tech2ipo希望通过案例的形式对商业网站如何加强社会化功能做一个系列话题。

网络经济是人气经济，没有人气不要谈什么模式。要想做大，首先要有人气。社区人气的三大推动力：SEO、事件、人。每位网友都是你争取的对象，每位参与互动的网友都是意见领袖，每一次事件都不要放过。用户上你的网站，必然是寻找某种价值。网站产品设计的核心，一是提供价值服务，一是网络营销的原则。