兰蔻御用运维总结之一

接下来的篇章，我首先是谈需求与技术，谈兰蔻的客户要求以及与之对应的运维结构，然后谈归纳总结，反思，感悟以及我的导师对我及我两个大学同学的评价。

首先讲述客户需求：

在谈客户需求之前，我想谈一下感触：就是工期比较紧张的情况下，一旦需求确定，就不要轻易修改，因为这样才能保证项目的按时完成，不然就会出现软件开发工程师不停的修改程序，运维工程师不断地调整服务器部署，项目经理疲于应付，承受来自客户和项目组成员两方面的压力。那这个项目就离见马克思不远了。

需求邮件内容如下：

1月11日开始推广兰蔻年度回馈活动的计划，请根据以下数据推算出大概的“爱兰蔻”"礼品随你挑“活动的流量，并对目前两台服务器做相关的压力测试。 
压力测试建议使用的工具：Microsoft Web Application Stress Tool 
请于12月31日前做好相关的压力测试，看看是否目前两台服务器在以下的资源推广的情况下，能否承受相应的流量。是否需要增加服务器。

     1月11日-1月13日 发送量：165万 
     1月25日 发送量： 53万

这是邮件关于需求部分的原内容，我直接Copy下来。对这封邮件进行一次解释：

邮件中提到的家有兰蔻这是一期的活动，活动的内容有：上传一张化妆桌上的兰蔻的图片，图片大小从几十k到10M以下，在网站的页面上展现的是缩略图，点击缩略图会看到经过压制的符合一定比例的图片，而不是原图。用户上传图片后，可以在附属栏中填写好朋友的邮件地址，请好朋友到此网站点击他的图片从而进行拉票活动。在此活动进行到第10天（包括第十天），兰蔻会根据图片的排名，在前20名的用户得到兰蔻的礼品。原拓扑图如下：

简单介绍一下软硬件配置：两台DellR610（Intel5504*2/4G/146*3/1000M网卡*4），FW是cisco5504（并发连接数：25000 用户数无限制，网络端口：8个快速以太网端口、1个SSC扩展插槽，网络吞吐量(Mbps)：150），介绍系统软件：操作系统Windows 标准版R2，web服务器Tomcat6.0.20，DBServer：MSSQL2008.

介绍一下JVM优化：

JVM优化： 
JVM的server版和client版的区别： 
JVM动态库有client和server两个版本，分别针对桌面应用和服务器应用做了相应的优化，client版本加载速度比较快，server版本加载速度比较慢但是运行速度比较快。 
操作手法： 
把%JAVA_HOME%\jar\bin中的server的文件夹拷贝到%JAVA_HOME%同一级目录的jre中的bin目录下，然后修改C:\Program Files\Java\jre6\lib\i386目录中的jvm.cfg，把-server KNOWN 放在-client KNOWN前面，然后保存。现在可以在dos窗口中写入命令：java -version来查看是否是server版本： 
C:\Documents and Settings\actop>java -version 
java version "1.6.0_17" 
Java(TM) SE Runtime Environment (build 1.6.0_17-b04) 
Java HotSpot(TM) Server VM (build 14.3-b01, mixed mode)

介绍一下web服务器的参数配置：

Server.xml:

<Connector port="80" address="192.168.0.2" protocol="org.apache.coyote.http11.Http11NioProtocol"  
                 maxHttpHeaderSize="8192"  URIEncoding="UTF-8" useBodyEncodingForURI="true" 
                 maxThreads="2000" minSpareThreads="75" maxSpareThreads="300"  
                 enableLookups="false" redirectPort="8443" acceptCount="2000" 
                 compression="on" compressionMinSize="2048" compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"   
                 connectionTimeout="50000" disableUploadTimeout="true"/> 

catalina.bat:

set JAVA_OPTS=-server -XX:+UseConcMarkSweepGC -Djava.rmi.server.hostname=XX.XX.XX.XX(your IP address) -Djava.awt.headless=true -Xms1400m -Xmx1400m -XX:NewSize=48m -XX:MaxNewSize=128m -XX:PermSize=128m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true 
set CATALINA_OPTS=-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9004 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false 
set CATALINA_OPTS=%CATALINA_OPTS% -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true

对以上参数做如下解释：

首先我们对tomcat6.0.20的新特性进行介绍：

首先讲协议部分：参见网上博文：

===========================================================================================================

[转]Tomcat 6 支持 NIO -- Tomcat的四种基于HTTP协议的Connector性能比较 
Tomcat 6 支持 NIO -- Tomcat的四种基于HTTP协议的Connector性能比较

Tomcat从5.5版本开始，支持以下四种Connector的配置分别为：

<Connector port="8081" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000" redirectPort="8443"/> 
<Connector port="8081" protocol="HTTP/1.1" connectionTimeout="20000"   redirectPort="8443"/> 
<Connector executor="tomcatThreadPool"  port="8081" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> 
<Connector executor="tomcatThreadPool" port="8081" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000" redirectPort="8443" /> 
我们姑且把上面四种Connector按照顺序命名为 NIO, HTTP, POOL, NIOP 
为了不让其他因素影响测试结果，我们只对一个很简单的jsp页面进行测试，这个页面仅仅是输出一个Hello World。假设地址是  http://tomcat1/test.jsp 
我们依次对四种Connector进行测试，测试的客户端在另外一台机器上用ab命令来完成，测试命令为： ab -c 900 -n 2000  http://tomcat1/test.jsp，最终的测试结果如下表所示(单位:平均每秒处理的请求数)： 
NIO    HTTP    POOL    NIOP 
281     65     208     365 
666     66     110     398 
692     65     66     263 
256     63     94     459 
440     67     145     363 
由这五组数据不难看出，HTTP的性能是很稳定，但是也是最差的，而这种方式就是Tomcat的默认配置。NIO方式波动很大，但没有低于280 的，NIOP是在NIO的基础上加入线程池，可能是程序处理更复杂了，因此性能不见得比NIO强；而POOL方式则波动很大，测试期间和HTTP方式一样，不时有停滞。 
由于linux的内核默认限制了最大打开文件数目是1024，因此此次并发数控制在900。 
尽管这一个结果在实际的网站中因为各方面因素导致，可能差别没这么大，例如受限于数据库的性能等等的问题。但对我们在部署网站应用时还是具有参考价值的。

===========================================================================================================

Connector:客户端和service之间的连接器。 protocol指定了该端口侦听的协议类型，maxHttpHeaderSize：Http的Header的最大限制 
URIEncoding：url传参时的编码格式 
useBodyEncodingForURI：根据相应该请求页面request.CharacterEncoding参数对数据进行重新编码 
maxThreads：Tomcat可创建的最大的线程数 
minSpareThreads：初始化创建的线程数 
maxSpareThreads：一旦创建的线程超过这个数，Tomcat就将关闭不再需要的Socket线程 
enableLookups：使用允许DNS查询，通常情况下设置为false，设置为false就直接返回ip地址 
acceptCount：当所有可以使用的处理请求的线程树都被使用时，可以放到请求队列中的请求数，超过这个数的请求将不予处理。其实，该属性与ServerSocket(int port,int backlog)中的backlog参数意义相同，具体可参考ServerSocket的JDK API 
connectionTimeout：网络连接超时，单位毫秒。设置为0表示永不超时 
compression="on" compressionMinSize="2048" compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" 在客户端请求网页后，从服务器端将网页文件压缩，再下载到客户端，由客户端的浏览器负责解压缩并浏览。相对于普通的浏览过程HTML ,CSS,Javascript , Text ，它可以节省40%左右的流量。更为重要的是，它可以对动态生成的，包括CGI、PHP , JSP , ASP , Servlet,SHTML等输出的网页也能进行压缩，压缩效率惊人 
1) compression="on" 打开压缩功能 
2) compressionMinSize="2048" 启用压缩的输出内容大小，这里面默认为2KB 
3) noCompressionUserAgents="gozilla, traviata" 对于以下的浏览器，不启用压缩 
4) compressableMimeType="text/html,text/xml" 压缩类型

disableUploadTimeout设置是否上传超时。

开始讲解catalina.bat中的参数设置：

-Xms：JVM初始化堆大小 
-Xmx：JVM堆最大值 
MaxPermSize为永久对象（如jdbc驱动，各种随jvm启动时加载的jar包）占用内存数。 
Xms 与 Xmx常规情况下应该设置成同样大小，否则会影响jvm性能。一般最大不超过2G。

本文转自guoli0813 51CTO博客，原文链接：http://blog.51cto.com/guoli0813/273230，如需转载请自行联系原作者