最近的項目，面臨情況如下：
1. 并發(fā)壓力大。平時并發(fā)連接大約在3000左右，高峰期是8000人上線訪問，預(yù)期未來會達到20,000人同時在線。
2. 受到網(wǎng)絡(luò)攻擊。系統(tǒng)是接在公網(wǎng)上致使網(wǎng)絡(luò)爬蟲和攻擊工具都可能給系統(tǒng)帶來未知壓力，甚至突然增加的并發(fā)訪問導致系統(tǒng)癱瘓。
3. 數(shù)據(jù)庫壓力大。有大量的數(shù)據(jù)庫訪問操作，并且SQL語句中含有COUNT(*)或者JOIN等消耗系統(tǒng)資源的代碼。
為了滿足應(yīng)用需要，特別對以下環(huán)境進行了調(diào)優(yōu)。系統(tǒng)基本配置如下：
HP-UX V11.11 2CPU 4G
HP JDK V1.5
Apusic V5.0
SQL Server 2005
系統(tǒng)硬件條件已經(jīng)確定，系統(tǒng)資源調(diào)用變化最頻繁的就是應(yīng)用服務(wù)器，因此應(yīng)用服務(wù)器所在的操作系統(tǒng)、Java虛擬機(Java Virtual Machine, JVM)和Apusic AS都需要調(diào)優(yōu)。而應(yīng)用服務(wù)器對數(shù)據(jù)庫的數(shù)據(jù)庫連接池大小也必定會影響數(shù)據(jù)庫服務(wù)器的相關(guān)壓力，因此最后再根據(jù)穩(wěn)定后的應(yīng)用服務(wù)器調(diào)整數(shù)據(jù)庫服務(wù)器配置。
1. 先調(diào)整JVM。這個先根據(jù)JVM所在的應(yīng)用服務(wù)器物理內(nèi)存的大小和JDK所支持的大小決定，建議是將空閑內(nèi)存的70%～80%分配給JVM使用。下面是Java啟動時用的配置參數(shù)：
-server -Xms1024m -Xmx1024m -Xmn?m -XX:MaxPermSize=256m -XX:NewSize=128m -XX:MaxNewSize=128m -XX:SurvivorRatio=8 -Xincgc、
注：1. 不同JDK在不同OS下所能使用的內(nèi)存大小是不同
?2. Heap的大小和分配現(xiàn)在設(shè)置的是經(jīng)驗值，是否調(diào)整最終還需要分析應(yīng)用來定，一般經(jīng)驗值已經(jīng)滿足需要。
?3. GC的機制對系統(tǒng)穩(wěn)定也比較重要，盡可能參考JDK提供的最新GC參數(shù)。
?4. 使用server版的JVM一般都會對應(yīng)用系統(tǒng)提升帶來幫助。
2. 再調(diào)整Apusic應(yīng)用服務(wù)器。因為并發(fā)壓力大，也意味著系統(tǒng)對CPU和內(nèi)存的資源消耗都會比較大，為保證應(yīng)用服務(wù)器的穩(wěn)定修改apusic.conf的配置如下（只保留了修改的部分）：
2.1. 線程池調(diào)整
?為了平衡用戶訪問速度與并發(fā)支持的關(guān)系，必須調(diào)整Apusic的線程池。調(diào)整前依據(jù)以下原則：
?● 每CPU50用戶的原則（線程池的設(shè)置可參考《Apusic AS V5.1線程池配置和調(diào)優(yōu)》）。
?● HTTPHandler是MuxHandler的三倍。
<SERVICE
??? CLASS="com.apusic.util.ThreadPoolService"
??? NAME="Apusic:service=ThreadPool,name=MuxHandler"
??? >
??? <ATTRIBUTE NAME="MaxThreads" VALUE="100"/>
??? <ATTRIBUTE NAME="MaxSpareThreads" VALUE="30"/>
??? <ATTRIBUTE NAME="MinSpareThreads" VALUE="30"/>
</SERVICE>
<SERVICE
??? CLASS="com.apusic.util.ThreadPoolService"
??? NAME="Apusic:service=ThreadPool,name=HTTPHandler"
??? >
??? <ATTRIBUTE NAME="MaxThreads" VALUE="300"/>
??? <ATTRIBUTE NAME="MaxSpareThreads" VALUE="100"/>
??? <ATTRIBUTE NAME="MinSpareThreads" VALUE="100"/>
</SERVICE>
2.2. Mux（多路復用服務(wù)）調(diào)優(yōu)。多路復用是將客戶端的服務(wù)申請分發(fā)給相應(yīng)的服務(wù)，如：HTTP服務(wù)、JMS服務(wù)等等。因此該服務(wù)對資源占用時間較短，不需要分配太多線程，只需要關(guān)注他的接收能力和申請排隊，保證申請不會丟失。
<SERVICE
??? CLASS="com.apusic.net.Muxer"
??? >
??? <ATTRIBUTE NAME="NumberSelectors" VALUE="2"/>
?<!-- 系統(tǒng)CPU核數(shù)，多個CPU使用多個Selectors可以加快并發(fā)處理能力 -->
??? <ATTRIBUTE NAME="Port" VALUE="80"/>
?<!-- 默認的服務(wù)端口 -->
??? <ATTRIBUTE NAME="Backlog" VALUE="50"/>
?<!-- TCP/IP的隊列大小，如果有大量客戶端連接超時，而服務(wù)器又沒有足夠的CPU壓力，可以調(diào)大這個值 -->
</SERVICE>
2.3. WEB服務(wù)調(diào)優(yōu)。
<SERVICE
??? CLASS="com.apusic.web.WebService"
??? >
??? <ATTRIBUTE NAME="NumberSelectors" VALUE="2"/>
?<!-- 系統(tǒng)CPU核數(shù)，多個CPU使用多個Selectors可以加快并發(fā)處理能力 -->
??? <ATTRIBUTE NAME="MaxKeepAliveConnections" VALUE="300"/>
?<!-- 最大保持KeepAlive的連接數(shù)，與HTTPHandler保持一致 -->
??? <ATTRIBUTE NAME="MaxKeepAliveRequests" VALUE="600"/>
?<!-- 最大保持KeepAlive的請求數(shù)，設(shè)HTTPHandler×2，大約一個連接支持兩次請求，如果服務(wù)器硬件條件允許可以再開大些 -->
??? <ATTRIBUTE NAME="WaitingClientTimeout" VALUE="15"/>
??? <ATTRIBUTE NAME="MaxWaitingClients" VALUE="200"/>
?<!-- 等待隊列滿了后，將客戶端請求拋棄的等待時間。如果關(guān)注系統(tǒng)反應(yīng)的及時性，就把這個值調(diào)小，還可以把請求隊列MaxWaitingClients調(diào)小；如果關(guān)注系統(tǒng)服務(wù)的有效性則要調(diào)大。-->
??? <ATTRIBUTE NAME="KeepAlive" VALUE="True"/>
?<!-- 默認打開KeepAlive，了解這個參數(shù)配置需要參看HTTP 1.1協(xié)議 -->
??? <ATTRIBUTE NAME="ServletReloadCheckInterval" VALUE="-1"/>
?<!-- 設(shè)為-1，意思就是不檢查，因為這個功能是為開發(fā)階段提供熱部署的 -->
??? <ATTRIBUTE NAME="KeepAliveTimeout" VALUE="15"/>
?<!-- 服務(wù)器關(guān)閉客戶端連接前等待下一次請求的時間，如果系統(tǒng)壓力較大可以將這個值設(shè)小，以便應(yīng)對更多的請求。 -->
</SERVICE>
2.3. Session服務(wù)
基本上采用默認值就可以了，如果需要配置集群才需要調(diào)整Session里面某些配置選項，具體可以參考Apusic集群配置。
2.4. 數(shù)據(jù)庫連接池服務(wù)
<datasources>
? <datasource name="test"
???? jndi-name="jdbc/test"
???? driver-class="net.sourceforge.jtds.jdbc.Driver"
???? url="Jdbc:jtds:sqlserver://192.168.0.1:1433/test"
???? min-spare-connections="50"
???? max-spare-connections="50"
???? max-connections="150"
???? initial-connections="50"
? >
??? <property name="user" value="sa"/>
??? <property name="test-before-reused" value="false"/>
??? <property name="password" value="test"/>
??? <property name="stmt-cache-size" value="50"/>
??? <property name="pre-fetch-size" value="50"/>
? </datasource>
</datasources>
min-spare-connections、max-spare-connections：在池中保留的空閑數(shù)據(jù)庫連接數(shù)；
initial-connections：初始化的空閑數(shù)據(jù)庫連接數(shù)；
三個值相同，保證在初始化時就有足夠的數(shù)據(jù)庫連接使用。
數(shù)據(jù)庫連接數(shù)×2＝HTTP線程池數(shù)目
注：max-connections在現(xiàn)實中被調(diào)小。因為數(shù)據(jù)庫服務(wù)器無法處理更多響應(yīng)，因此原則是先保證擁有數(shù)據(jù)庫連接的線程能夠有效響應(yīng)。
3. 調(diào)整HP-UX操作系統(tǒng)。
3.1. 首先調(diào)整核心資源，使用ulimit -a查看核心參數(shù)，特別關(guān)注file和memory兩部分的使用，有些時候操作系統(tǒng)限制了進程打開文件數(shù)和內(nèi)存使用數(shù)，無法有效利用硬件資源也會限制應(yīng)用服務(wù)器性能的發(fā)揮。
3.2. 因為應(yīng)用系統(tǒng)受到攻擊，致使出現(xiàn)大量的CLOSE_WAIT、FIN_WAIT_2這樣狀態(tài)的連接，消耗大量系統(tǒng)資源。因此使用ndd進行網(wǎng)絡(luò)參數(shù)配置，先用：ndd /dev/tcp，然后輸入?，可以得到所有網(wǎng)絡(luò)參數(shù)情況。使用：ndd -get /dev/tcp 參數(shù)名稱，可以獲得原參數(shù)的值。使用：ndd -set /dev/tcp 參數(shù)名稱 參數(shù)值，可以設(shè)置新參數(shù)的值。例如：獲得初始值：ndd -get /dev/tcp tcp_time_wait_interval，設(shè)置新值：ndd -set /dev/tcp tcp_time_wait_interval 30000，30000是毫秒單位=30秒。不能設(shè)置為0，0似乎是無限長的意思。需要關(guān)注的參數(shù)如下：
#與TIME_WAIT相關(guān)的參數(shù)，當系統(tǒng)出現(xiàn)大量此狀態(tài)的連接時可以調(diào)小這個值
tcp_time_wait_interval ??30000
tcp_tw_cleanup_interval ?60000
#與FIN_WAIT相關(guān)的參數(shù)
tcp_fin_wait_2_timeout? ?1000
#與KeepAlive相關(guān)的參數(shù)，因為應(yīng)用服務(wù)器不負責KeepAlive連接的管理，因此這里由操作系統(tǒng)負責
tcp_keepalive_interval ??120000
tcp_keepalive_detached_interval?120000
tcp_keepalives_kill ??1
tcp_ip_abort_interval ??600000
#與TCP連接數(shù)相關(guān)的參數(shù)
tcp_conn_request_max ??4096
注：使用ndd重新啟動后就無效了。可以修改/etc/rc.config.d/nddconf就可以在機器重新啟動時有效。
4. 調(diào)整SQL Server數(shù)據(jù)庫的參數(shù)。這個是因為數(shù)據(jù)庫壓力較大，才關(guān)注到這個部分調(diào)優(yōu)。
4.1. 內(nèi)存調(diào)整。因為SQL Server內(nèi)存管理默認無限大，結(jié)果把系統(tǒng)資源全部耗盡，因此將服務(wù)器內(nèi)存按照70～80%原則分配給SQL Server使用。
4.2. 處理器設(shè)置。主要是選擇提升SQL Server的優(yōu)先級和使用Windows纖程，保證SQL Server在操作系統(tǒng)中的執(zhí)行速度。
4.3. 連接設(shè)置。控制最大并發(fā)連接數(shù)，比數(shù)據(jù)庫連接池所設(shè)的連接數(shù)稍大就可以了，防止過多連接導致系統(tǒng)切換線程帶來的資源消耗。同時合理設(shè)置查詢的超時時間，保證資源不會被某個訪問占用。
4.4. 活動監(jiān)視器。通過活動監(jiān)視器查看系統(tǒng)中的活動進程，以及執(zhí)行的SQL語句，并且在系統(tǒng)壓力較大時觀察是否有資源被鎖。
?不過這些其實都只是幫助系統(tǒng)更好的運行，實際上SQL Server資源消耗問題的解決仍然領(lǐng)先應(yīng)用的調(diào)整，應(yīng)用發(fā)現(xiàn)某些表關(guān)聯(lián)有問題，重新調(diào)整后CPU壓力立刻降低。
?以上是整個調(diào)優(yōu)的過程記錄。