Apache性能调优.docxVIP

Web Server结合App Server实现单向Https的这样的一个 HYPERLINK /base/architecture \o 大型网站架构知识库 \t _blank 架构。这个架构是一个非常基础的J2ee工程上线布署时的一种架构。在前两天的教程中，还讲述了Http服务器、App Server的最基本安全配置（包括单向https的实现）， 它只是避免了用户可以通过浏览器侵入我们的Web访问器或者能够通过Web浏览器来查询我们的Web目录结构及其目录内的文件与相关内容，这种入侵我们把它称为： Directory traversal，当然我们只是实现了最基本的防范Directory traversal的手段，在日后的Security课程中将会详细地去擅述完整的Web Security的相关理论。 从今天起我们将继续在原有的这种Apache+Tomat的架构上，去论述如何在性能及Performance上优化这个架构，因此这两天的课程在有些人看来，可能会有些“枯燥”，所以我在此给大家打个招呼： 这两天的课程论述???是如何在不改动代码与SQL语句的前提下，如何去改善和提高web server与app server的性能，千万不要小觑这一内容，它可以让你在不改动代码的情况下得到10-20倍以上的性能提高，网上有其它的大牛们写过一篇文章叫“Tomcat如何支持到1000个用户”，经本人经过几个重大工程的实践，Opensource的Tomcat如果调优的好不只可以支持者1000个用户，尤其当你的布署环境是64位 HYPERLINK /base/operatingsystem \o 操作系统知识库 \t _blank 操作系统的情况下，可能能够支持更大更高的并发性能，最后本节内容将会以Tomcat集群来做收场，在将来的课程中还会进一步详细讲述Weblogic的集群配置与IBM WASND的集群配置。 二、从性能测试谈起 2.1?性能测试简介 即压力 HYPERLINK /base/softwaretest \o 软件测试知识库 \t _blank 测试，就是根据一定数量的VU（Virtual Users）我称为并发用户操作核心交易后，系统所能达到的最大瓶劲，以便于发现系统的极限、有没有Outof memory这样的问题存在以及相关的系统设置、配置是否搭挡的合理的一种测试。 一般商业的比较好的用LoaderRunner，如果没钱的就用Opensource的Jmeter来模拟这个VU的操作。 压力测试，存在几个误区，需要小心。 1）??无限大的拼命增加VU的数量 系统再完美，硬件配置再高，也经不住没有经过合理运算的VU的压力呀。 2）??偏执的用一定的数据量的VU，跑7*24小时 不是说这个没必要，很有必要，小日本的电视为什么寿命敢说比中国人生产的电视机寿命长？因为它用一个机械臂就对着电视机的按钮不断的点点点。 我们说的压力测试要测试多长时间，关键是要看经过科学计算的VU的数量以及核心交易数有多少，不是说我拿250个VU跑24*7如果没有问题我这个系统就没有问题了，这样的说法是不对的，错误的。随便举个例子就能把你推倒。 假设我有250个VU，同时跑上万笔交易，每个VU都有上万笔交易，250个VU一次跑下来可能就要数个小时，你又怎么能断定250个VU对于这样的系统我跑24*7小时就能真的达到上万笔交易在250个VU的并发操作下能够真的跑完7天的全部交易？可能需要一周半或者两周呢？对吧？ 我还看到过有人拿500个VU对着一条交易反复跑24*7小时。。。这样的测试有意义吗？你系统就仅仅只有一条交易？你怎么能够判断这条交易涉及到的数据量最大？更不用说交易是彼此间有依赖的，可能a+b+c+d的交易的一个混合组织就能够超出你单笔交易所涉及到的数据量了呢！ 2.2?合理的制定系统最大用户、并发用户 提供下面这个公式，以供大家在平时或者日常需要进行的性能测试中作为一个参考。 （1）????????计算平均的并发用户数：C = nL/T 公式（1）中，C是平均的并发用户数；n是login session的数量；L是login session的平均长度；T指考察的时间段长度。 （2）????????并发用户数峰值：C’ ≈ C+3根号C 公式（2）则给出了并发用户数峰值的计算方式中，其中，C’指并发用户数的峰值，C就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的loginsession产生符合泊松分布而估算得到的。 实例： 假设有一个OA系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在一天的时间内，用户只在8小时内使用该系统。