門戶類網(wǎng)站性能測(cè)試分析及調(diào)優(yōu)

1、門戶類網(wǎng)站性能測(cè)試分析及調(diào)優(yōu)1背景前段時(shí)間，性能測(cè)試團(tuán)隊(duì)經(jīng)歷了一個(gè)規(guī)模較大的門戶網(wǎng)站的性能優(yōu)化工作，該網(wǎng)站的開(kāi) 發(fā)和合作涉及多個(gè)組織和部門，而且網(wǎng)站的重要性不言而喻，同時(shí)上線時(shí)間非常緊迫，關(guān)注度 也很高，所以對(duì)于整個(gè)團(tuán)隊(duì)的壓力也非常大。在此，把整個(gè)經(jīng)歷過(guò)程給大家分享一下，包括了主要包括了如何使用性能測(cè)試的壓測(cè)工 具，壓測(cè)前的性能問(wèn)題評(píng)估，以及壓測(cè)執(zhí)行后的性能問(wèn)題分析、瓶頸定位。該門戶網(wǎng)站的服務(wù)器是放在華通和阿里云的平臺(tái)上的，所以對(duì)華通和阿里共建的云平臺(tái) 安全及應(yīng)急措施方面要求非常高，需要團(tuán)隊(duì)給予全力的保障和配合。性能測(cè)試(Performance Testing )是集測(cè)試機(jī)管理、測(cè)試腳本管理、

2、測(cè)試場(chǎng)景管理、測(cè) 試任務(wù)管理、測(cè)試結(jié)果管理為一體的性能云測(cè)試平臺(tái)，可以幫助您全方位的評(píng)估云上系統(tǒng)性能。本次優(yōu)化主要是使用了該測(cè)試平臺(tái)服務(wù)對(duì)客戶搭建在ECS上的服務(wù)器進(jìn)行多種類型(性能測(cè)試、負(fù)載測(cè)試、壓力測(cè)試、穩(wěn)定性測(cè)試、混合場(chǎng)景測(cè)試、異常測(cè)試等)的性能壓測(cè)、調(diào)試 和分析，最終達(dá)到滿足期望預(yù)估的性能目標(biāo)值，且上線后在高峰期滿足實(shí)際的性能和穩(wěn)定要求。2術(shù)語(yǔ)定義在介紹項(xiàng)目經(jīng)歷之前，再明確一下測(cè)試當(dāng)中用到的專業(yè)指標(biāo)術(shù)語(yǔ)定義，包括但不僅限于以下：PV:即PageView,即頁(yè)面瀏覽量或點(diǎn)擊量，用戶每次刷新即被計(jì)算一次。我們可以認(rèn)為， 用戶的一次刷新，給服務(wù)器造成了一次請(qǐng)求。UV:即UniqueVisit

3、or, 訪問(wèn)您網(wǎng)站的一臺(tái)電腦客戶端為一個(gè)訪客。00:00-24:00 內(nèi)相同的客戶端只被計(jì)算一次。TPS:TPS(Transaction Per Second)每秒鐘系統(tǒng)能夠處理的交易或事務(wù)的數(shù)量，它是衡量系統(tǒng)處理能力的重要指標(biāo)。響應(yīng)時(shí)間：響應(yīng)時(shí)間是指從客戶端發(fā)一個(gè)請(qǐng)求開(kāi)始計(jì)時(shí)，到客戶端接收到從服務(wù)器端返回 的響應(yīng)結(jié)果結(jié)束所經(jīng)歷的時(shí)間，響應(yīng)時(shí)間由請(qǐng)求發(fā)送時(shí)間、網(wǎng)絡(luò)傳輸時(shí)間和服務(wù)器處理時(shí)間三 部分組成。VU: Virtual user ,模擬真實(shí)業(yè)務(wù)邏輯步驟的虛擬用戶，虛擬用戶模擬的操作步驟都被記錄在虛擬用戶腳本里。一般性能測(cè)試過(guò)程中，通俗稱之為并發(fā)用戶數(shù)。TPS波動(dòng)：系統(tǒng)性能依賴于特定的硬件、

4、軟件代碼、應(yīng)用服務(wù)、網(wǎng)絡(luò)資源等，所以在性能 場(chǎng)景執(zhí)行期間，TPS可能會(huì)表現(xiàn)為穩(wěn)定，或者波動(dòng)，抑或遵循一定的上升或下降趨勢(shì)。我們用 TPS波動(dòng)系數(shù)來(lái)記錄這個(gè)指標(biāo)值。CPU: CPU資源是指性能測(cè)試場(chǎng)景運(yùn)行的這個(gè)時(shí)間段內(nèi)，應(yīng)用服務(wù)系統(tǒng)的CPU資源占用率。CPU資源是判斷系統(tǒng)處理能力以及應(yīng)用運(yùn)行是否穩(wěn)定的重要參數(shù)。Load:系統(tǒng)正在干活的多少的度量，隊(duì)列長(zhǎng)度。系統(tǒng)平均負(fù)載，被定義為在特定時(shí)間間隔(1m , 5m , 15m )內(nèi)運(yùn)行隊(duì)列中的平均進(jìn)程數(shù)OI/O: I/O 可分為磁盤(pán)IO和網(wǎng)卡IO。JVM:即java虛擬機(jī)，它擁有自己的處理器、堆棧、寄存器等，還有自己相應(yīng)的指令系 統(tǒng)。Java應(yīng)用運(yùn)行在

5、 JVM上面。GC: GC是一種自動(dòng)內(nèi)存管理程序，它主要的職責(zé)是分配內(nèi)存、保證被引用的對(duì)象始終在內(nèi)存中、把不被應(yīng)用的對(duì)象從內(nèi)存中釋放。FGC會(huì)引起JVM掛起。網(wǎng)速：網(wǎng)絡(luò)中的數(shù)據(jù)傳輸速率，一般以 Byte/s為單位。通過(guò)ping延時(shí)來(lái)反映網(wǎng)速。流量：性能測(cè)試中，一般指單位時(shí)間內(nèi)流經(jīng)網(wǎng)卡的總流量。分為 inbound 和outbound 一般以KB為單位。3評(píng)估本次性能測(cè)試過(guò)程的參與人包括了阿里云應(yīng)急保障小組等多部門人員，網(wǎng)站為外部供應(yīng) 商開(kāi)發(fā)，阿里云提供云主機(jī)和技術(shù)支持。該網(wǎng)站之前前期也由其他部門做了驗(yàn)收工作，進(jìn)行了完整的性能測(cè)試，報(bào)告顯示，性能較差，第一次測(cè)試，網(wǎng)站并發(fā)數(shù)沒(méi)有超過(guò)35個(gè)，第二次

6、測(cè)試，網(wǎng)站上做了優(yōu)化后，靜態(tài)頁(yè)面縮小后，并發(fā)用戶數(shù) 100內(nèi)5s , 200內(nèi)90%響應(yīng)在15s以上，隨著并發(fā)用戶數(shù)的增加，頁(yè) 面響應(yīng)最高可到20多秒，而且訪問(wèn)明顯感覺(jué)較慢，所以聯(lián)系了阿里云的技術(shù)支持，希望能夠 幫助診斷性能問(wèn)題，給出優(yōu)化建議。測(cè)試業(yè)務(wù)并發(fā)用戶數(shù)平均響應(yīng)時(shí)間(秒)90%響應(yīng)首頁(yè)瀏覽10012.08215.28920023.94929.092分頁(yè)瀏覽1008.97312.34320018.84624.106測(cè)試業(yè)務(wù)90%響應(yīng)并發(fā)用戶數(shù)平均響應(yīng)時(shí)間（秒）經(jīng)過(guò)會(huì)議討論后，評(píng)估出最終的測(cè)試目標(biāo)：帶頁(yè)面的所有靜態(tài)資源一起，響應(yīng)時(shí)間必須 小于5秒，同時(shí)并發(fā)訪問(wèn)用戶數(shù)最低500 , TPS根

7、據(jù)實(shí)際的結(jié)果來(lái)得出。4性能測(cè)試目標(biāo)并發(fā)用戶數(shù)：=500業(yè)務(wù)響應(yīng)時(shí)間：5秒5分析通過(guò)性能測(cè)試前端分析工具 （未開(kāi)放）分析，頁(yè)面的響應(yīng)時(shí)間 88%左右都是消耗在前端資源加載上，服務(wù)器端消耗只占到了頁(yè)面響應(yīng)的12%左右；一個(gè)網(wǎng)站的響應(yīng)一般由四部分時(shí)間組成，前端、網(wǎng)絡(luò)、服務(wù)器和數(shù)據(jù)庫(kù)，前端主要是減小頁(yè)面大小，減小頁(yè)面請(qǐng)求數(shù)，優(yōu)化頁(yè)面js等，網(wǎng)絡(luò)主要是使用 CDN ,優(yōu)化連接數(shù)等，服務(wù)器主要是優(yōu)化 Apache ,優(yōu)化Tomcat ,優(yōu)化java代碼等，數(shù)據(jù)庫(kù)是優(yōu)化sql語(yǔ)句，優(yōu)化索引,優(yōu)化數(shù)據(jù)存儲(chǔ)等。rb6測(cè)試和優(yōu)化頁(yè)面前端分析及優(yōu)化我們對(duì)頁(yè)面的優(yōu)化仍然從前端開(kāi)始，首先通過(guò)性能測(cè)試的前端測(cè)試工具（未開(kāi)

8、放）進(jìn)行 掃描，我們發(fā)現(xiàn)以下問(wèn)題并優(yōu)化：Js較大，無(wú)壓縮，同時(shí)存在重復(fù)請(qǐng)求，最多一個(gè)js加載4次，已做壓縮和減少。Js位置不合理，阻礙頁(yè)面加載。外部css考慮本地實(shí)現(xiàn)，減少調(diào)用Banner背景圖片較多，無(wú)壓縮，建議合并頁(yè)面1的后臺(tái).do有4個(gè)，減少為3個(gè)頁(yè)面2的后臺(tái)do有2個(gè)，減少為1個(gè)存在加載失敗鏈接，404失敗，同時(shí)次數(shù)非常多，更換為 cnzz頁(yè)面加載外部資源失敗 （qq等），且不穩(wěn)定分享功能比較慢外部資源建議異步實(shí)現(xiàn)，目前全部是jquery渲染，iframe嵌套，時(shí)間資源限制，后期優(yōu)化盡量減少或者不使用iframe頁(yè)面請(qǐng)求數(shù)太多，主要是 js和css重復(fù)加載問(wèn)題和圖片較小導(dǎo)致的。經(jīng)過(guò)以上

9、修改及配置服務(wù)器靜態(tài)資源緩存后，性能提高25%,首頁(yè)響應(yīng)從1.5秒提高到1.1秒，并且前端優(yōu)化持續(xù)進(jìn)行。服務(wù)端優(yōu)化一般核心頁(yè)面都要求在 300毫秒以下，非核心頁(yè)面要求在500毫秒以下，同時(shí)重點(diǎn)關(guān)注并發(fā)時(shí)的負(fù)載和穩(wěn)定，服務(wù)器端代碼和響應(yīng)的快速穩(wěn)定是整個(gè)頁(yè)面性能的重點(diǎn)。腳本編寫(xiě)及場(chǎng)景構(gòu)造根據(jù)前期需求評(píng)估的內(nèi)容，客戶是一個(gè)門戶網(wǎng)站，主要由不同功能頁(yè)面組成的，各個(gè)功 能頁(yè)面當(dāng)中又包含了靜態(tài)內(nèi)容和異步動(dòng)態(tài)請(qǐng)求，所以，性能測(cè)試的腳本的編寫(xiě)主要涵蓋了各頁(yè) 面的請(qǐng)求和相關(guān)靜態(tài)資源的請(qǐng)求，這里存在一個(gè)串行和并行的概念：串行：請(qǐng)求的頁(yè)面和頁(yè)面當(dāng)中的靜態(tài)資源、異步動(dòng)態(tài)請(qǐng)求組成一個(gè)同步請(qǐng)求，每一個(gè)內(nèi) 容都作為一個(gè)事務(wù)

10、（也可以共同組成一個(gè)事務(wù)，分開(kāi)事務(wù)的好處是可以統(tǒng)計(jì)各部分的響應(yīng)時(shí) 間），這樣壓測(cè)任務(wù)執(zhí)行時(shí)，線程就會(huì)根據(jù)事物的順序分布調(diào)用執(zhí)行，相當(dāng)于一個(gè)頁(yè)面的順序 加載，弊端是無(wú)法模擬實(shí)際IE的小范圍并發(fā)，但這樣測(cè)試的結(jié)果是最嚴(yán)格的。并行：各個(gè)頁(yè)面之前可以使用不同的任務(wù)，采用并行的混合場(chǎng)景執(zhí)行，同時(shí)設(shè)置一定的 比例（并發(fā)用戶數(shù)），保證服務(wù)器承受的壓力與實(shí)際用戶訪問(wèn)相似。場(chǎng)景并發(fā)用戶數(shù)： 經(jīng)常會(huì)遇到“設(shè)置多大并發(fā)用戶數(shù)合適？ ”的問(wèn)題，因?yàn)樵跊](méi)有任何 思考時(shí)間的時(shí)候，我們有一個(gè)簡(jiǎn)單的公式：VU （并發(fā)壓測(cè)用戶數(shù)）=TPS （每秒執(zhí)行事務(wù)數(shù)）X RT （響應(yīng)時(shí)間）所以，在尋找合適的并發(fā)用戶數(shù)上，建議使用性能測(cè)試

11、的“梯度模式”，逐漸增加并發(fā) 用戶數(shù)，這個(gè)時(shí)候壓力也會(huì)越來(lái)越大，當(dāng)TPS的增長(zhǎng)率小于響應(yīng)時(shí)間的增長(zhǎng)率時(shí)，這就是性能的拐點(diǎn)，也就是最合理的并發(fā)用戶數(shù)；當(dāng)TPS不再增長(zhǎng)或者下降時(shí)，這個(gè)時(shí)候的壓力就是最大的壓力，所使用的并發(fā)用戶數(shù)就是最大的并發(fā)用戶數(shù)。如果此時(shí)的TPS不滿足你的要求,那么就需要尋找瓶頸來(lái)優(yōu)化。如下圖演示的一個(gè)性能曲線：fl50ur4】打.iRi尢RMmOH 1.23CK4 .e弊.iWifrl r141*1 lijHL& m z00 OM)EQ1 fei服務(wù)器資源消耗較高，超過(guò) 75% ,存在瓶頸，分析平臺(tái)顯示:修54Ttar*Z r WTcqnf-Lw wwdH aHJlBKflb

12、 pv* mihr e工mh七七十ft Nii f 3 I Pr MOiivap |w lit .1 hl if lidl.l h I W-ILllSjHflJituirH .物，-，Ej |J|fl hlupiLrai毒Mlr 2Our hjO till hM * /wki iriJita 4!iuWii4# IEEE皿 分析發(fā)現(xiàn)原來(lái)是 apache到tomcat的連接等待導(dǎo)致，現(xiàn)象是 100個(gè)并發(fā)壓測(cè)，就有100個(gè) tomcat的java線程，而且全部是runnable 的狀態(tài)，輪詢很耗時(shí)間。同時(shí)發(fā)現(xiàn)用戶使用的是http協(xié)議，非ajp協(xié)議，不過(guò)這個(gè)改動(dòng)較大，需要使用mod_jk模塊,時(shí)間原

13、因， 暫緩。解決方法：修改了 Apache和tomcat的連接協(xié)議 為nio協(xié)議，同時(shí)去除 ssl協(xié)議。Tomcat 連接數(shù)據(jù)庫(kù)池由30初始調(diào)整為300 ,減少開(kāi)銷性能對(duì)比:再進(jìn)行1輪壓測(cè)含動(dòng)態(tài)含靜態(tài)文件，TPS能夠從1w達(dá)到2.7W，性能提高將近3倍，并且tomcat的線程從原來(lái)的200跑滿，降到100附近并且線程沒(méi)有持續(xù)跑滿，2.6W TPS時(shí)候CPU在80%附近發(fā)現(xiàn)機(jī)器的核數(shù)都是 2核，8G內(nèi)存，對(duì)于CPU達(dá)到98%的情況，CPU是瓶頸，而對(duì)于應(yīng)用 來(lái)說(shuō)比較浪費(fèi)，所以將 2核統(tǒng)一升級(jí)為4核。擴(kuò)展機(jī)器資源，從目前的 4臺(tái)擴(kuò)到6臺(tái)，同時(shí)準(zhǔn)備4臺(tái)備份，以應(yīng)對(duì)訪問(wèn)量較大的情況。思考和風(fēng)險(xiǎn)：異步請(qǐng)

14、求處理：客戶所提供的url都是html靜態(tài)，雖然頁(yè)面當(dāng)中含動(dòng)態(tài)數(shù)據(jù)，但分析后發(fā)現(xiàn)動(dòng) 態(tài)數(shù)據(jù)都是通過(guò)jquery執(zhí)行然后iframe嵌套的，所以不會(huì)隨著 html文件的加載而自動(dòng)加載, 需要分析所有的動(dòng)態(tài)頁(yè)面，同時(shí)壓測(cè)，這是頁(yè)面存在異步請(qǐng)求需要關(guān)注的地方。Iframe: Iframe嵌套頁(yè)面的方式優(yōu)點(diǎn)是靜態(tài)資源調(diào)用方便、頁(yè)面和程序可以分離，但是它的缺 點(diǎn)也顯而易見(jiàn)，包括樣式、腳本額外注入，增加請(qǐng)求等等；還有搜索引擎搜素不到內(nèi)容； iframe創(chuàng)建比其他元素慢 12個(gè)數(shù)量級(jí)；資源重復(fù)加載；iframe會(huì)阻塞頁(yè)面加載，阻塞 onload事件；占用主頁(yè)連接池；html5不再支持。所以建議盡量不要使用或

15、者少使用。font=Times New Roman:腳本錄制和模擬實(shí)際用戶訪問(wèn)。當(dāng)用戶的圖片、javascript、CSS等靜態(tài)資源和后端代碼在同一臺(tái)服務(wù)器上時(shí)，需要模擬用戶的實(shí)際訪問(wèn)請(qǐng)求，壓測(cè)腳本涵 蓋所有鏈接和資源。那么使用腳本錄制功能就可以采集更全更完整的腳本。6.2.3第二階段找到幾個(gè)頁(yè)面的所有動(dòng)態(tài)資源后，整合成為一個(gè)事務(wù)，串行訪問(wèn)，同時(shí)并發(fā)壓測(cè)，從而 對(duì)純服務(wù)器端進(jìn)行壓測(cè)，測(cè)試結(jié)果如下圖：JUHTjHWKaitir0眸HIMITT?ogurn?格 Rn 1 JTf0gHIMWW1771A*IEE1W0二蛙TjlX0wgrfrlDnhlnw:門EHMMQgLL7L1 IMRU1BTJ,

16、ginrviIITPS中g(shù)ihk5秒和2秒，性能較差，整體 TPS只性能分析：頁(yè)面一和頁(yè)面二的響應(yīng)時(shí)間分別達(dá)到了有11性能分析：分析發(fā)現(xiàn)響應(yīng)時(shí)間高的原因主要在RDS數(shù)據(jù)庫(kù)上，數(shù)據(jù)庫(kù)此時(shí)的CPU已經(jīng)達(dá)到100%,處理較慢，懷疑跟 sql有關(guān)，分析慢sql。優(yōu)化方法：數(shù)據(jù)庫(kù)第一批優(yōu)化完畢，優(yōu)化了6條sql語(yǔ)句之前5s左右，優(yōu)化后在150ms左右，數(shù)據(jù)庫(kù)的QPS從1k上升到6k。RDS優(yōu)化內(nèi)容包括：優(yōu)化點(diǎn)主要是調(diào)整慢 sql的索引，部分sql需要調(diào)整表結(jié)構(gòu)和 sql寫(xiě)法，需要應(yīng)用配合才 能完成優(yōu)化，優(yōu)化前 QPS在1000左右，優(yōu)化后 QPS到達(dá)6000前端響應(yīng)時(shí)間從 5秒降低到150毫秒，前臺(tái)TP

17、S由150提升到1500.總的TPS可以達(dá)到2000 。第三階段通過(guò)性能測(cè)試模擬用戶實(shí)際訪問(wèn)情況，包括所有靜態(tài)資源，評(píng)估出當(dāng)響應(yīng)時(shí)間小于5秒的時(shí)候，最大支撐的并發(fā)用戶數(shù)。測(cè)試結(jié)果:. 一. . 79 -.1： * * *：fi 0，卜VMI 申*FfTf滸5位tK-Wt6tlMUtim效HMilflMAT仇3ITMTiMBYWNliQmmpr：1M113uiibGngJH0s可以看到，所有的事務(wù) RT加起來(lái)小于5秒的情況下，并發(fā)用戶數(shù)可以達(dá)到3000（6個(gè)事務(wù)，6個(gè)腳本，每個(gè)腳本 500）,遠(yuǎn)遠(yuǎn)滿足項(xiàng)目500個(gè)并發(fā)用戶的目標(biāo)。* 總結(jié):壓測(cè)項(xiàng)目?jī)?yōu)化前優(yōu)化后頁(yè)面一并發(fā)用戶數(shù);100平均響應(yīng)時(shí)問(wèn):

18、5sCPU負(fù)載自轂上不去并發(fā)用戶JR3000平均響曲時(shí)間:5&CPU負(fù)裁的%面IPS平均響應(yīng)時(shí)間CPU負(fù)羲TPS:1500平均藺應(yīng)時(shí) 241msCPU負(fù)S:90%RDSQpsaoooQPS:7000第四階段評(píng)估其他非主站應(yīng)用的性能以及含靜態(tài)頁(yè)面的其他5個(gè)頁(yè)面內(nèi)容，包括:搜索壓測(cè)操作壓測(cè)登錄壓測(cè)證書(shū)登入針對(duì)5個(gè)常用場(chǎng)景進(jìn)行混合壓測(cè)測(cè)試結(jié)果：EHwnxnwNfFm(5)暹濡TF5qr3gCPUCjJIdi=一：_IL輔C 1才”iT.?aj*3511.4UI*1：4)0I.一泗,119仆nS-50 jcoo4CK科wo 1發(fā)現(xiàn)的風(fēng)險(xiǎn)和問(wèn)題：測(cè)試發(fā)現(xiàn)，流量存在非常明顯的波動(dòng)，不經(jīng)過(guò)某模塊就無(wú)此問(wèn)題，

19、發(fā)現(xiàn)有大量的reset連接，會(huì)診后總結(jié)：端口復(fù)用導(dǎo)致的問(wèn)題。FULL NAT模式和LVS存在兼容性問(wèn)題。最終結(jié)果 ：由于存在兼容性問(wèn)題，影響到網(wǎng)站的穩(wěn)定性和性能，暫時(shí)加載該模塊，待問(wèn)題解決后再加。先使用 另外一個(gè)模塊代替,.凌晨2點(diǎn)，針對(duì)單點(diǎn)用戶登入進(jìn)行了壓測(cè)，發(fā)現(xiàn) 100并發(fā)，該業(yè)務(wù)接口已宕機(jī)，分析結(jié)果:Cache緩存設(shè)置太小，1G內(nèi)存容量導(dǎo)致內(nèi)存溢出，已建議修改為4G。使用http協(xié)議性能不佳，早上4點(diǎn)30進(jìn)行少量代碼優(yōu)化后，業(yè)務(wù)直接不可用，環(huán)境出現(xiàn)宕機(jī)無(wú)法修復(fù)，我們快速進(jìn)行快照恢復(fù)，5分鐘內(nèi)恢復(fù)3臺(tái)業(yè)務(wù)機(jī)，云產(chǎn)品的優(yōu)勢(shì)盡顯。用戶10g日志撐滿系統(tǒng)盤(pán)，并且一直不知這臺(tái)云主機(jī)還有數(shù)據(jù)盤(pán)，產(chǎn)品

20、上我們要做反思。幫助用戶已進(jìn)行掛盤(pán)及日志遷移 至數(shù)據(jù)盤(pán)，減少單盤(pán)的IO壓力。 Web服務(wù)器數(shù)據(jù)同步，發(fā)現(xiàn)服務(wù)器io和cpu壓力過(guò)大。加入inotify機(jī)制，由文件增量同步,變更為文件系統(tǒng)的變化通知機(jī)制。將冷備及4臺(tái)備用web機(jī)器使用該方式同步，目前，查看內(nèi)容分發(fā)主機(jī)IO和CPU使用率已回復(fù)正常范圍同步推送時(shí)間，根據(jù)服務(wù)器的負(fù)載，進(jìn)行調(diào)整 同步時(shí)間。今天已修改為2分鐘。由于備份量大，晚上進(jìn)行全量同步。新增 4臺(tái)備用機(jī)，已關(guān)閉apache端口自動(dòng)從slb去除，作為冷備由于目前單點(diǎn)用戶登入入口存在架構(gòu)單點(diǎn)宕機(jī)風(fēng)險(xiǎn)，進(jìn)行登入和未登入風(fēng)險(xiǎn)驗(yàn)證，確認(rèn)，如用 戶已登入后，登入業(yè)務(wù)系統(tǒng)出現(xiàn)宕機(jī)，進(jìn)行簡(jiǎn)單的頁(yè)面點(diǎn)擊切換，不受影響內(nèi)存優(yōu)按照J(rèn)VM內(nèi)存管理模式，調(diào)整系統(tǒng)啟動(dòng)參數(shù)，如果一臺(tái)ECS部署一臺(tái)服務(wù)器，建議不要選擇默認(rèn)的JVM配置，應(yīng)該設(shè)置內(nèi)存為物理內(nèi)存的一半，同時(shí)設(shè)置相應(yīng)的YTC和FGC策略,觀察Old區(qū)變化，避免大量 Full GC ,建議Full GC頻率大于1小時(shí)，同時(shí) GC時(shí)間小于1秒 鐘。6.3架構(gòu)優(yōu)化單點(diǎn)登錄服務(wù)修改為 SLB* 檢索修改為SLB內(nèi)容管理云平臺(tái)云服務(wù)器實(shí)現(xiàn)行文件差異同步，同時(shí)冷備新增4臺(tái)web機(jī)器7總結(jié)正刮咬目?jī)?yōu)化前優(yōu)化后頁(yè)面一并發(fā)用戶數(shù):1