2010年的1月11號之后的日子對我而言，是一個艱苦奮斗的歷程。我把這次的運維經歷稱之為：蘭蔻御用一戰。剛開始我就知道蘭蔻一役，需要總結，反思的會很多。可是怎么也不會想到這次總結竟然是一場暴風驟雨。 接下來的篇章，我首先是談需求與技術，談蘭蔻的客戶要求以及與之對應的運維結構，然后談歸納總結，反思，感悟以及我的導師對我及我兩個大學同學的評價。 首先講述客戶需求： 在談客戶需求之前，我想談一下感觸：就是工期比較緊張的情況下，一旦需求確定，就不要輕易修改，因為這樣才能保證項目的按時完成，不然就會出現軟件開發工程師不停的修改程序，運維工程師不斷地調整服務器部署，項目經理疲于應付，承受來自客戶和項目組成員兩方面的壓力。那這個項目就離見馬克思不遠了。 需求郵件內容如下： 1月11日開始推廣蘭蔻年度回饋活動的計劃，請根據以下數據推算出大概的“愛蘭蔻”"禮品隨你挑“活動的流量，并對目前兩臺服務器做相關的壓力測試。
壓力測試建議使用的工具：Microsoft Web Application Stress Tool
請于12月31日前做好相關的壓力測試，看看是否目前兩臺服務器在以下的資源推廣的情況下，能否承受相應的流量。是否需要增加服務器。

• 短信發送（2次）

1月11日-1月13日 發送量：165萬
???? 1月25日 發送量： 53萬

• EDM發送（1次）

大概會在1月20或21日 發送量： 20萬
這是郵件關于需求部分的原內容，我直接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。

轉載于:https://blog.51cto.com/guoli0813/273230

總結

以上是生活随笔為你收集整理的兰蔻御用运维总结之一的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。