服務性能演算法優化

⑴ linux系統性能怎麼優化

linux系統性能怎麼優化
一、前提
我們可以在文章的開始就列出一個列表，列出可能影響Linux操作系統性能的一些調優參數，但這樣做其實並沒有什麼價值。因為性能調優是一個非常困難的任務，它要求對硬體、操作系統、和應用都有著相當深入的了解。如果性能調優非常簡單的話，那些我們要列出的調優參數早就寫入硬體的微碼或者操作系統中了，我們就沒有必要再繼續讀這篇文章了。正如下圖所示，伺服器的性能受到很多因素的影響。
當面對一個使用單獨IDE硬碟的，有20000用戶的資料庫伺服器時，即使我們使用數周時間去調整I/O子系統也是徒勞無功的，通常一個新的驅動或者應用程序的一個更新(如SQL優化)卻可以使這個伺服器的性能得到明顯的提升。正如我們前面提到的，不要忘記系統的性能是受多方面因素影響的。理解操作系統管理系統資源的方法將幫助我們在面對問題時更好的判斷應該對哪個子系統進行調整。
二、Linux的CPU調度
任何計算機的基本功能都十分簡單，那就是計算。為了實現計算的功能就必須有一個方法去管理計算資源、處理器和計算任務(也被叫做線程或者進程)。非常感謝Ingo Molnar，他為Linux內核帶來了O(1)CPU調度器，區別於舊有的O(n)調度器，新的調度器是動態的，可以支持負載均衡，並以恆定的速度進行操作。
新調度器的可擴展性非常好，無論進程數量或者處理器數量，並且調度器本身的系統開銷更少。新調取器的演算法使用兩個優先順序隊列。
引用
・活動運行隊列
・過期運行隊列
調度器的一個重要目標是根據優先順序許可權有效地為進程分配CPU 時間片，當分配完成後它被列在CPU的運行隊列中，除了 CPU 的運行隊列之外，還有一個過期運行隊列。當活動運行隊列中的一個任務用光自己的時間片之後，它就被移動到過期運行隊列中。在移動過程中，會對其時間片重新進行計算。如果活動運行隊列中已經沒有某個給定優先順序的任務了，那麼指向活動運行隊列和過期運行隊列的指針就會交換，這樣就可以讓過期優先順序列表變成活動優先順序的列表。通常互動式進程(相對與實時進程而言)都有一個較高的優先順序，它佔有更長的時間片，比低優先順序的進程獲得更多的計算時間，但通過調度器自身的調整並不會使低優先順序的進程完全被餓死。新調度器的優勢是顯著的改變Linux內核的可擴展性，使新內核可以更好的處理一些有大量進程、大量處理器組成的企業級應用。新的O(1)調度器包含仔2.6內核中，但是也向下兼容2.4內核。
新調度器另外一個重要的優勢是體現在對NUMA(non-uniform memory architecture)和SMP(symmetric multithreading processors)的支持上，例如INTEL@的超線程技術。
改進的NUMA支持保證了負載均衡不會發生在CECs或者NUMA節點之間，除非發生一個節點的超出負載限度。
三、Linux的內存架構
今天我們面對選擇32位操作系統還是64位操作系統的情況。對企業級用戶它們之間最大的區別是64位操作系統可以支持大於4GB的內存定址。從性能角度來講，我們需要了解32位和64位操作系統都是如何進行物理內存和虛擬內存的映射的。
在上面圖示中我們可以看到64位和32位Linux內核在定址上有著顯著的不同。
在32位架構中，比如IA-32，Linux內核可以直接定址的范圍只有物理內存的第一個GB(如果去掉保留部分還剩下896MB)，訪問內存必須被映射到這小於1GB的所謂ZONE_NORMAL空間中，這個操作是由應用程序完成的。但是分配在ZONE_HIGHMEM中的內存頁將導致性能的降低。
在另一方面，64位架構比如x86-64(也稱作EM64T或者AMD64)。ZONE_NORMAL空間將擴展到64GB或者128GB(實際上可以更多，但是這個數值受到操作系統本身支持內存容量的限制)。正如我們看到的，使用64位操作系統我們排除了因ZONE_HIGHMEM部分內存對性能的影響的情況。
實際中，在32位架構下，由於上面所描述的內存定址問題，對於大內存，高負載應用，會導致死機或嚴重緩慢等問題。雖然使用hugemen核心可緩解，但採取x86_64架構是最佳的解決辦法。
四、虛擬內存管理
因為操作系統將內存都映射為虛擬內存，所以操作系統的物理內存結構對用戶和應用來說通常都是不可見的。如果想要理解Linux系統內存的調優，我們必須了解Linux的虛擬內存機制。應用程序並不分配物理內存，而是向Linux內核請求一部分映射為虛擬內存的內存空間。如下圖所示虛擬內存並不一定是映射物理內存中的空間，如果應用程序有一個大容量的請求，也可能會被映射到在磁碟子系統中的swap空間中。
另外要提到的是，通常應用程序不直接將數據寫到磁碟子系統中，而是寫入緩存和緩沖區中。Bdflush守護進程將定時將緩存或者緩沖區中的數據寫到硬碟上。
Linux內核處理數據寫入磁碟子系統和管理磁碟緩存是緊密聯系在一起的。相對於其他的操作系統都是在內存中分配指定的一部分作為磁碟緩存，Linux處理內存更加有效，默認情況下虛擬內存管理器分配所有可用內存空間作為磁碟緩存，這就是為什麼有時我們觀察一個配置有數G內存的Linux系統可用內存只有20MB的原因。
同時Linux使用swap空間的機制也是相當高效率的，如上圖所示虛擬內存空間是由物理內存和磁碟子系統中的swap空間共同組成的。如果虛擬內存管理器發現一個已經分配完成的內存分頁已經長時間沒有被調用，它將把這部分內存分頁移到swap空間中。經常我們會發現一些守護進程，比如getty，會隨系統啟動但是卻很少會被應用到。這時為了釋放昂貴的主內存資源，系統會將這部分內存分頁移動到swap空間中。上述就是Linux使用swap空間的機制，當swap分區使用超過50%時，並不意味著物理內存的使用已經達到瓶頸了，swap空間只是Linux內核更好的使用系統資源的一種方法。
簡單理解：Swap usage只表示了Linux管理內存的有效性。對識別內存瓶頸來說，Swap In/Out才是一個比較又意義的依據，如果Swap In/Out的值長期保持在每秒200到300個頁面通常就表示系統可能存在內存的瓶頸。下面的事例是好的狀態：
引用
# vmstat
procs ———–memory————- —swap– —–io—- –system– —-cpu—-
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 5696 6904 28192 50496 0 0 88 117 61 29 11 8 80 1
五、模塊化的I/O調度器
就象我們知道的Linux2.6內核為我們帶來了很多新的特性，這其中就包括了新的I/O調度機制。舊的2.4內核使用一個單一的I/O調度器，2.6 內核為我們提供了四個可選擇的I/O調度器。因為Linux系統應用在很廣闊的范圍里，不同的應用對I/O設備和負載的要求都不相同，例如一個筆記本電腦和一個10000用戶的資料庫伺服器對I/O的要求肯定有著很大的區別。
引用
(1).Anticipatory
anticipatory I/O調度器創建假設一個塊設備只有一個物理的查找磁頭(例如一個單獨的SATA硬碟)，正如anticipatory調度器名字一樣，anticipatory調度器使用「anticipatory」的演算法寫入硬碟一個比較大的數據流代替寫入多個隨機的小的數據流，這樣有可能導致寫 I/O操作的一些延時。這個調度器適用於通常的一些應用，比如大部分的個人電腦。
(2).Complete Fair Queuing (CFQ)
Complete Fair Queuing(CFQ)調度器是Red Flag DC Server 5使用的標准演算法。CFQ調度器使用QoS策略為系統內的所有任務分配相同的帶寬。CFQ調度器適用於有大量計算進程的多用戶系統。它試圖避免進程被餓死和實現了比較低的延遲。
(3).Deadline
deadline調度器是使用deadline演算法的輪詢的調度器，提供對I/O子系統接近實時的操作，deadline調度器提供了很小的延遲和維持一個很好的磁碟吞吐量。如果使用deadline演算法請確保進程資源分配不會出現問題。
(4).NOOP
NOOP調度器是一個簡化的調度程序它只作最基本的合並與排序。與桌面系統的關系不是很大，主要用在一些特殊的軟體與硬體環境下，這些軟體與硬體一般都擁有自己的調度機制對內核支持的要求很小，這很適合一些嵌入式系統環境。作為桌面用戶我們一般不會選擇它。
六、網路子系統
新的網路中斷緩和(NAPI)對網路子系統帶來了改變，提高了大流量網路的性能。Linux內核在處理網路堆棧時，相比降低系統佔用率和高吞吐量更關注可靠性和低延遲。所以在某些情況下，Linux建立一個防火牆或者文件、列印、資料庫等企業級應用的性能可能會低於相同配置的Windows伺服器。
在傳統的處理網路封包的方式中，如下圖藍色箭頭所描述的，一個乙太網封包到達網卡介面後，如果MAC地址相符合會被送到網卡的緩沖區中。網卡然後將封包移到操作系統內核的網路緩沖區中並且對CPU發出一個硬中斷，CPU會處理這個封包到相應的網路堆棧中，可能是一個TCP埠或者Apache應用中。
這是一個處理網路封包的簡單的流程，但從中我們可以看到這個處理方式的缺點。正如我們看到的，每次適合網路封包到達網路介面都將對CPU發出一個硬中斷信號，中斷CPU正在處理的其他任務，導致切換動作和對CPU緩存的操作。你可能認為當只有少量的網路封包到達網卡的情況下這並不是個問題，但是千兆網路和現代的應用將帶來每秒鍾成千上萬的網路數據，這就有可能對性能造成不良的影響。
正是因為這個情況，NAPI在處理網路通訊的時候引入了計數機制。對第一個封包，NAPI以傳統的方式進行處理，但是對後面的封包，網卡引入了POLL 的輪詢機制：如果一個封包在網卡DMA環的緩存中，就不再為這個封包申請新的中斷，直到最後一個封包被處理或者緩沖區被耗盡。這樣就有效的減少了因為過多的中斷CPU對系統性能的影響。同時，NAPI通過創建可以被多處理器執行的軟中斷改善了系統的可擴展性。NAPI將為大量的企業級多處理器平台帶來幫助，它要求一個啟用NAPI的驅動程序。在今天很多驅動程序默認沒有啟用NAPI，這就為我們調優網路子系統的性能提供了更廣闊的空間。
七、理解Linux調優參數
因為Linux是一個開源操作系統，所以又大量可用的性能監測工具。對這些工具的選擇取決於你的個人喜好和對數據細節的要求。所有的性能監測工具都是按照同樣的規則來工作的，所以無論你使用哪種監測工具都需要理解這些參數。下面列出了一些重要的參數，有效的理解它們是很有用處的。
(1)處理器參數
引用
・CPU utilization
這是一個很簡單的參數，它直觀的描述了每個CPU的利用率。在xSeries架構中，如果CPU的利用率長時間的超過80%，就可能是出現了處理器的瓶頸。
・Runable processes
這個值描述了正在准備被執行的進程，在一個持續時間里這個值不應該超過物理CPU數量的10倍，否則CPU方面就可能存在瓶頸。
・Blocked
描述了那些因為等待I/O操作結束而不能被執行的進程，Blocked可能指出你正面臨I/O瓶頸。
・User time
描述了處理用戶進程的百分比，包括nice time。如果User time的值很高，說明系統性能用在處理實際的工作。
・System time
描述了CPU花費在處理內核操作包括IRQ和軟體中斷上面的百分比。如果system time很高說明系統可能存在網路或者驅動堆棧方面的瓶頸。一個系統通常只花費很少的時間去處理內核的操作。
・Idle time
描述了CPU空閑的百分比。
・Nice time
描述了CPU花費在處理re-nicing進程的百分比。
・Context switch
系統中線程之間進行交換的數量。
・Waiting
CPU花費在等待I/O操作上的總時間，與blocked相似，一個系統不應該花費太多的時間在等待I/O操作上，否則你應該進一步檢測I/O子系統是否存在瓶頸。
・Interrupts
Interrupts 值包括硬Interrupts和軟Interrupts，硬Interrupts會對系統性能帶來更多的不利影響。高的Interrupts值指出系統可能存在一個軟體的瓶頸，可能是內核或者驅動程序。注意Interrupts值中包括CPU時鍾導致的中斷(現代的xServer系統每秒1000個 Interrupts值)。
(2)內存參數
引用
・Free memory
相比其他操作系統，Linux空閑內存的值不應該做為一個性能參考的重要指標，因為就像我們之前提到過的，Linux內核會分配大量沒有被使用的內存作為文件系統的緩存，所以這個值通常都比較小。
・Swap usage
這 個值描述了已經被使用的swap空間。Swap usage只表示了Linux管理內存的有效性。對識別內存瓶頸來說，Swap In/Out才是一個比較又意義的依據，如果Swap In/Out的值長期保持在每秒200到300個頁面通常就表示系統可能存在內存的瓶頸。
・Buffer and cache
這個值描述了為文件系統和塊設備分配的緩存。在Red Flag DC Server 5版本中,你可以通過修改/proc/sys/vm中的page_cache_tuning來調整空閑內存中作為緩存的數量。
・Slabs
描述了內核使用的內存空間，注意內核的頁面是不能被交換到磁碟上的。
・Active versus inactive memory
提供了關於系統內存的active內存信息，Inactive內存是被kswapd守護進程交換到磁碟上的空間。
(3)網路參數
引用
・Packets received and sent
這個參數表示了一個指定網卡接收和發送的數據包的數量。
・Bytes received and sent
這個參數表示了一個指定網卡接收和發送的數據包的位元組數。
・Collisions per second
這個值提供了發生在指定網卡上的網路沖突的數量。持續的出現這個值代表在網路架構上出現了瓶頸，而不是在伺服器端出現的問題。在正常配置的網路中沖突是非常少見的，除非用戶的網路環境都是由hub組成。
・Packets dropped
這個值表示了被內核丟掉的數據包數量，可能是因為防火牆或者是網路緩存的缺乏。
・Overruns
Overruns表達了超出網路介面緩存的次數，這個參數應該和packets dropped值聯繫到一起來判斷是否存在在網路緩存或者網路隊列過長方面的瓶頸。
・Errors 這個值記錄了標志為失敗的幀的數量。這個可能由錯誤的網路配置或者部分網線損壞導致，在銅口千兆乙太網環境中部分網線的損害是影響性能的一個重要因素。
(4)塊設備參數
引用
・Iowait
CPU等待I/O操作所花費的時間。這個值持續很高通常可能是I/O瓶頸所導致的。
・Average queue length
I/O請求的數量，通常一個磁碟隊列值為2到3為最佳情況，更高的值說明系統可能存在I/O瓶頸。
・Average wait
響應一個I/O操作的平均時間。Average wait包括實際I/O操作的時間和在I/O隊列里等待的時間。
・Transfers per second
描述每秒執行多少次I/O操作(包括讀和寫)。Transfers per second的值與kBytes per second結合起來可以幫助你估計系統的平均傳輸塊大小，這個傳輸塊大小通常和磁碟子系統的條帶化大小相符合可以獲得最好的性能。
・Blocks read/write per second
這個值表達了每秒讀寫的blocks數量，在2.6內核中blocks是1024bytes，在早些的內核版本中blocks可以是不同的大小，從512bytes到4kb。
・Kilobytes per second read/write
按照kb為單位表示讀寫塊設備的實際數據的數量。

⑵ 網站性能優化怎麼辦

一、前端優化

網站性能優化是一個很綜合的話題，涉及到伺服器的配置和網站前後端程序等各個方面，我只是從實際經歷出發，分享一下自己所嘗試過的網站性能優化方法。之所以在標題上掛一個web2.0，是因為本文更偏重於中小網站的性能優化，我所使用的系統也是典型web2.0的LAMP架構。

首先講講前端的優化，用戶訪問網頁的等待時間，有80%是發生在瀏覽器前端，特別是頁面和頁面中各種元素（圖片、CSS、javascript、 flash…）的下載之上。因此在很多情況下，相對於把大量的時間花在艱苦而繁雜的程序改進上，前端的優化往往能起到事半功倍的作用。雅虎最近將內部使用的性能測試工具yslow向第三方公開，並發布了著名的網站性能優化的十三條規則，建議你下載並安裝yslow，並作為測評網站優化效果的工具。下面我挑其中特別有價值的具體說明一下優化的方法：

對於第一次訪問您網站，尚未在瀏覽器cache中緩存您網站內容的用戶，我們可以做的事情包括：

1）減少一個頁面訪問所產生的http連接次數
對於第一次訪問你網站的用戶，頁面所產生的http連接次數是影響性能的一個關鍵瓶頸。

對策：
- 盡量簡潔的頁面設計，最大程度減少圖片的使用，通過放棄一些不必要的頁面特效來減少javascript的使用。
- 使用一些優化技巧，比如利用圖片的背景位移減少圖片的個數；image map技術；使用Inline images將css圖片捆綁到網頁中。
- 盡量合並js和css文件，減少獨立文件個數。

2) 使用gzip壓縮網頁內容
使用gzip來壓縮網頁中的靜態內容，能夠顯著減少用戶訪問網頁時的等待時間（據說可達到60%）。主流的web伺服器都支持或提供gzip壓縮，如果使用apache伺服器，只需要在配置文件中開啟 mod_gzip（apache1.x）或mod_deflate(apache2.x)即可。凡是靜態的頁面，使用gzip壓縮都能夠顯著提高伺服器效率並減少帶寬支出，注意圖片內容本身已經是壓縮格式了，務必不要再進行壓縮。

3）將CSS放在頁面頂端，JS文件放在頁面底端
CSS的引用要放在html的頭部header中，JS文件引用盡量放在頁面底端標簽的後面，主要的思路是讓核心的頁面內容盡早顯示出來。不過要注意，一些大量使用js的頁面，可能有一些js文件放在底端會引起一些難以預料的問題，根據實際情況適當運用即可。

4）使JS文件內容最小化
具體來說就是使用一些javascript壓縮工具對js腳本進行壓縮，去除其中的空白字元、注釋，最小化變數名等。在使用gzip壓縮的基礎上，對js內容的壓縮能夠將性能再提高5%。

5）盡量減少外部腳本的使用，減少DNS查詢時間
不要在網頁中引用太多的外部腳本，首先，一次dns的解析過程會消耗20-120毫秒的時間；其次，如果在頁面中引用太多的外部文件（如各種廣告、聯盟等代碼），可能會因為外部文件的響應速度而將你的網站拖得很慢。如果不得不用，那麼就盡量將這些腳本放在頁腳吧。不過有一點需要提及，就是瀏覽器一般只能並行處理同一域名下的兩個請求，而對於不同子的域名則不受此限制，因此適當將本站靜態內容（css,js）放在其他的子域名下（如 static.xxx.com）會有利於提高瀏覽器並行下載網頁內容的能力。

對於您網站的經常性訪問用戶，主要的優化思路就是最大限度利用用戶瀏覽器的cache來減少伺服器的開銷。

1）在header中添加過期時間(Expires Header)
在header中給靜態內容添加一個較長的過期時間，這樣可以使用戶今後訪問只讀取緩存中的文件，而不會與伺服器產生任何的交互。不過這樣做也存在一些問題，當圖片、CSS和js文件更新時，用戶如果不刷新瀏覽器，就無法獲得此更新。這樣，我們在對圖片、css和js文件修改時，必須要進行重命名，才能保證用戶訪問到最新的內容。這可能會給開發造成不小的麻煩，因為這些文件可能被站點中的許多文件所引用。flickr提出的解決辦法是通過url rewrite使不同版本號的URL事實上指向同一個文件，這是一個聰明的辦法，因為url級別的操作效率是很高的，可以給開發過程提供不少便利。

要理解為什麼這樣做，必須要了解瀏覽器訪問url時的工作機制：
a. 第一次訪問url時，用戶從伺服器段獲取頁面內容，並把相關的文件（images,css,js…）放在高速緩存中，也會把文件頭中的expired time,last modified, ETags等相關信息也一同保留下來。
b. 用戶重復訪問url時，瀏覽器首先看高速緩存中是否有本站同名的文件，如果有，則檢查文件的過期時間；如果尚未過期，則直接從緩存中讀取文件，不再訪問伺服器。
c. 如果緩存中文件的過期時間不存在或已超出，則瀏覽器會訪問伺服器獲取文件的頭信息，檢查last modifed和ETags等信息，如果發現本地緩存中的文件在上次訪問後沒被修改，則使用本地緩存中的文件；如果修改過，則從伺服器上獲取最新版本。

我的經驗，如果可能，盡量遵循此原則給靜態文件添加過期時間，這樣可以大幅度減少用戶對伺服器資源的重復訪問。

2）將css和js文件放在獨立外部文件中引用
將css和js文件放在獨立文件中，這樣它們會被單獨緩存起來，在訪問其他頁面時可以從瀏覽器的高速緩存中直接讀取。一些網站的首頁可能是例外的，這些首頁的自身瀏覽可能並不大，但卻是用戶訪問網站的第一印象以及導向到其他頁面的起點，也可能這些頁面本身使用了大量的ajax局部刷新及技術，這時可以將 css和js文件直接寫在頁面中。

3）去掉重復的腳本
在IE中，包含重復的js腳本會導致瀏覽器的緩存不被使用，仔細檢查一下你的程序，去掉重復引用的腳本應該不是一件很難的事情。

4）避免重定向的發生
除了在header中人為的重定向之外，網頁重定向常在不經意間發生，被重定向的內容將不會使用瀏覽器的緩存。比如用戶在訪問www.xxx.com，伺服器會通過301轉向到www.xxx.com/，在後面加了一個「/」。如果伺服器的配置不好，這也會給伺服器帶來額外的負擔。通過配置apache的 alias或使用mod_rewrite模塊等方法，可以避免不必要的重定向。

還有一些，比如使用CDN分發機制、避免CSS表達式等、避免使用ETags等，因為不太常用，這里就不再贅述了。

做完了上述的優化，可以試著用yslow測試一下網頁的性能評分，一般都可以達到70分以上了。

當然，除了瀏覽器前端和靜態內容的優化之外，還有針對程序腳本、伺服器、資料庫、負載的優化，這些更深層次的優化方法對技術有更高的要求。本文的後半部分將重點探討後端的優化。

二、後端優化

上次寫完web2.0網站前端優化篇之後，一直想寫寫後端優化的方法，今天終於有時間將思路整理了出來。

前端優化可以避免我們造成無謂的伺服器和帶寬資源浪費，但隨著網站訪問量的增加，僅靠前端優化已經不能解決所有問題了，後端軟體處理並行請求的能力、程序運 行的效率、硬體性能以及系統的可擴展性，將成為影響網站性能和穩定的關鍵瓶頸所在。優化系統和程序的性能可以從以下的方面來入手：

1）apache、mysql等軟體的配置的優化
盡管apache和mysql等軟體在安裝後使用的默認設置足以使你的網站運行起來，但是通過調整mysql和apache的一些系統參數，還是可以追求更高的效率和穩定性。這個領域中有很多專業的文章和論壇（比如： http://www.mysqlperformanceblog.com/），要想掌握也需要進行深入的研究和實踐，這里就不重點討論了。

2）應用程序環境加速
這里僅以我最常應用的php開發環境為例，有一些工具軟體可以通過優化PHP運行環境來達到提速的目的，其基本原理大致是將PHP代碼預編譯並緩存起來，而不需要改變任何代碼，所以比較簡單，可以將php的運行效率提升50%以上。比較常用的免費php加速工具有：APC( http: //pecl.php.net/package-info.php?package=APC)、Turck MMCache（ http://turck-mmcache.sourceforge.net）、php accelebrator(www.php-accelerator.co.uk)，還有收費的Zend Performance Suite

3）將靜態內容和動態內容分開處理
apache是一個功能完善但比較龐大的web server，它的資源佔用基本上和同時運行的進程數呈正比，對伺服器內存的消耗比較大，處理並行任務的效率也一般。在一些情況下，我們可以用比較輕量級的web server來host靜態的圖片、樣式表和javascript文件，這樣可以大大提升靜態文件的處理速度，還可以減少對內存佔用。我使用的web server是來自俄羅斯的nginx，其他選擇方案還包括lighttpd和thttpd等。

4）基於反向代理的前端訪問負載均衡
當一台前端伺服器不足以應付用戶訪問時，通過前端機實現web訪問的負載均衡是最快速可行的方案。通過apache的mod_proxy可以實現基於反向代理的負載均衡，這里推薦使用nginx做代理伺服器，處理速度較apache更快一些。

5）應用緩存技術提高資料庫效能，文件緩存和分布式緩存
資料庫訪問處理並發訪問的能力是很多網站應用的關鍵瓶頸，在想到使用主從結構和多farm的方式構建伺服器集群之前，首先應該確保充分使用了資料庫查詢的緩存。一些資料庫類型（如mysql的innoDB）自身內置對緩存的支持，此外，還可以利用程序方法將常用的查詢通過文件或內存緩存起來。比如通過 php中的ob_start和文件讀寫函數可以很方便的實現文件形式的緩存，而如果你擁有多台伺服器，可以通過memcache技術通過分布式共享內存來對資料庫查詢進行緩存，不僅效率高而且擴展性好，memcache技術在livejournal和Craigslist.org等知名網站應用中都得到了檢驗。

6）伺服器運行狀態的檢測，找到影響性能的瓶頸所在
系統優化沒有一勞永逸的方法，需要通過檢測伺服器的運行狀態來及時發現影響性能的瓶頸，以及可能存在的潛在問題，因為網站的性能，永遠取決於木桶中的短板。可以編寫一些腳本來檢測web服務的運行，也有一些開源的軟體也提供了很好的功能

7）良好的擴展架構是穩定和性能的基礎
一些技巧和竅門可以幫你度過眼前的難關，但要想使網站具備應付大規模訪問的能力，則需要從系統架構上進行徹底的規劃，好在很多前人無私的把他們架構
網站的經驗分享給我們，使我們可以少走甚多彎路。我最近讀到的兩篇有啟發的文章：
- 從LiveJournal後台發展看大規模網站性能優化方法
- Myspace的六次重構

最後不得不提到程序編碼和資料庫結構對性能的影響，一系列糟糕的循環語句，一個不合理的查詢語句、一張設計不佳的數據表或索引表，都足以會使應用程序運行的速度成倍的降低。培養全局思考的能力，養成良好的編程習慣，並對資料庫運行機制有所了解，是提高編程質量的基礎。

⑶ Windows Server伺服器網路性能優化

TcpTimedWaitDelay ：確定 TCP/IP 可釋放已關閉連接並重用其資源前，必須經過的時間。關閉和釋放之間的此時間間隔通稱 TIME_WAIT 狀態或兩倍最大段生命周期（2MSL）狀態。此時間期間，重新打開到客戶機和伺服器的連接的成本少於建立新連接。減少此條目的值允許 TCP/IP 更快地釋放已關閉的連接，為新連接提供更多資源。如果運行的應用程序需要快速釋放和創建新連接，而且由於 TIME_WAIT 中存在很多連接，導致低吞吐量，則調整此參數。

MaxUserPort ：確定在應用程序從系統請求可用用戶埠時，TCP/IP 可指定的最高埠號。 如何查看或設置： 使用 regedit 命令訪問 HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/ Services/TCPIP/Parameters 注冊表子鍵並創建名為 MaxUserPort 的新 REG_DWORD 值。 停止並重新啟動系統。 預設值：無 建議值：至少十進制 32768。 註：現在 Windows NT 或 Windows 2000 操作系統上調整 WebSphere Application Server 時，同時使用這兩個參數。

將以下代碼，保存為reg文件，在伺服器上雙擊導入注冊表即可。

⑷ 如何提高高性能伺服器並發量

消除瓶頸是提高伺服器性能和並發能力的唯一途徑。 如果你能夠消除所有的瓶頸，你就能夠最大的發揮硬體性能，讓系統的性能和並發數到達最佳。 採用多線程多核編程，使用事件驅動或非同步消息機制，盡量減少阻塞和等待操作（如I/O阻塞、同步等待或計時/超時等）。 原理： 1、多線程多核編程，消除cpu瓶頸。 2、採用IOCP或epoll，利用狀態監測和通知方式，消除網路I/O阻塞瓶頸。 3、採用事件驅動或非同步消息機制，可以消除不必要的等待操作。 4、如果是Linux，可以採用AIO來消除磁碟I/O阻塞瓶頸。 5、在事件驅動框架或非同步消息中統一處理timer事件，變同步為非同步，而且可以在一個線程處理無數timer事件。 6、深入分析外部的阻塞來源，消除它。 比如資料庫查詢較慢，導致伺服器處理較慢，並發數上不去，這時就要優化資料庫性能。 7、如果與某個其他server通信量很大，導致性能下降較多。 可以考慮把這兩個server放在一個主機上，採用共享內存的方式來做IPC通信，可以大大提高性能。

⑸ 高性能計算的優化

高性能計算(HighPerformanceComputing)是計算機科學的一個分支，主要是指從體系結構、並行演算法和軟體開發等方面研究開發高性能計算機的技術。
隨著計算機技術的飛速發展，高性能計算機的計算速度不斷提高，其標准也處在不斷變化之中。
高性能計算簡單來說就是在16台甚至更多的伺服器上完成某些類型的技術工作負載。到底這個數量是需要8台，12台還是16台伺服器這並不重要。在定義下假設每一台伺服器都在運行自己獨立的操作系統，與其關聯的輸入/輸出基礎構造都是建立在COTS系統之上。
簡而言之，討論的就是Linux高性能計算集群。
一個擁有20000台伺服器的信息中心要進行分子動力學模擬無疑是毫無問題的，就好比一個小型工程公司在它的機房裡運行計算流體動力學(CFD)模擬。解決工作負載的唯一限制來自於技術層面。接下來我們要討論的問題是什麼能直接加以應用。
量度(Metrics)
性能(Performance)，每瓦特性能(Performance/Watt)，每平方英尺性能(Performance/Squarefoot)和性能價格比(Performance/dollar)等，對於提及的20000台伺服器的動力分子簇來說，原因是顯而易見的。運行這樣的系統經常被伺服器的能量消耗(瓦特)和體積(平方英尺)所局限。這兩個要素都被計入總體擁有成本(TCO)之列。在總體擁有成本(TCO)方面取得更大的經濟效益是大家非常關注的。
議題的范圍限定在性能方面來幫助大家理解性能能耗，性能密度和總體擁有成本(TCO)在實踐中的重要性。
性能的定義
在這里把性能定義為一種計算率。例如每天完成的工作負載，每秒鍾浮點運算的速度(FLOPs)等等。接下來要思考的是既定工作量的完成時間。這兩者是直接關聯的，速度=1/(時間/工作量)。因此性能是根據運行的工作量來進行測算的，通過計算其完成時間來轉化成所需要的速度。
定量與定性
從定性的層面上來說這個問題很容易回答，就是更快的處理器，更多容量的內存，表現更佳的網路和磁碟輸入/輸出子系統。但當要在決定是否購買Linu集群時這樣的回答就不夠准確了。
對Linux高性能計算集群的性能進行量化分析。
為此介紹部分量化模型和方法技巧，它們能非常精確的對大家的業務決策進行指導，同時又非常簡單實用。舉例來說，這些業務決策涉及的方麵包括：
購買---系統元件選購指南來獲取最佳性能或者最經濟的性能配置---鑒別系統及應用軟體中的瓶頸
計劃---突出性能的關聯性和局限性來制定中期商業計劃
Linux高性能計算集群模型包括四類主要的硬體組成部分。
(1)執行技術工作負載的計算節點或者伺服器；
(2)一個用於集群管理，工作控制等方面的主節點；
(3)互相連接的電纜和高度普及的千兆乙太網(GBE)；
(4)一些全局存儲系統，像由主節點輸出的NFS文件一樣簡單易用。
高性能計算機的衡量標准主要以計算速度(尤其是浮點運算速度)作為標准。高性能計算機是信息領域的前沿高技術，在保障國家安全、推動國防科技進步、促進尖端武器發展方面具有直接推動作用，是衡量一個國家綜合實力的重要標志之一。
隨著信息化社會的飛速發展，人類對信息處理能力的要求越來越高，不僅石油勘探、氣象預報、航天國防、科學研究等需求高性能計算機，而金融、政府信息化、教育、企業、網路游戲等更廣泛的領域對高性能計算的需求迅猛增長。
一個簡單量化的運用模型
這樣一個量化的運用模型非常直觀。在一個集群上對既定的工作完成的時間大約等同於在獨立的子系統上花費的時間：
e
1、時間(Time)=節點時間(Tnode)+電纜時間(Tfabric)+存儲時間(Tstorage)
Time = Tnode + Tfabric + Tstorag
這里所說的時間(Time)指的是執行工作量的完成時間，節點時間(Tnode)是指在計算節點上花費的完成時間，電纜時間(Tfabric)是指在互聯網上各個節點進行互聯的完成時間，而存儲時間(Tstorage)則是指訪問區域網或全球存儲系統的完成時間。
計算節點的完成時間大約等同於在獨立的子系統上花費的時間：
2、節點時間(Tnode)=內核時間(Tcore) +內存時間(Tmemory)
這里所說的內核時間(Tcore)指的是在微處理器計算節點上的完成時間。而內存時間(Tmemory)就是指訪問主存儲器的完成時間。這個模型對於單個的CPU計算節點來說是非常實用的，而且能很容易的擴展到通用雙插槽(SMP對稱多處理)計算節點。為了使第二套模型更加實用，子系統的完成時間也必須和計算節點的物理配置參數相關聯，例如處理器的速度，內存的速度等等。
計算節點
圖示中的計算節點原型來認識相關的配置參數。圖示上端的是2個處理器插槽，通過前端匯流排(FSB-front side bus)與內存控制中心(MCH)相連。這個內存控制中心(MCH)有四個存儲信道。同時還有一個Infiniband HCA通過信道點對點串列(PCIe)連接在一起。
像千兆乙太網和串列介面(SATA)硬碟之類的低速的輸入輸出系統都是通過晶元組中的南橋通道(South Bridge)相連接的。在圖示中，大家可以看到每個主要部件旁邊都用紅色標注了一個性能相關參數。這些參數詳細的說明了影響性能(並非全部)的硬體的特性。它們通常也和硬體的成本直接相關。舉例來說，處理器時鍾頻率(fcore)在多數工作負荷狀態下對性能影響巨大。根據供求交叉半導體產額曲線原理，處理器速度越快，相應成本也會更高。
高速緩存存儲器的體積也會對性能產生影響，它能減少主頻所承載的工作負荷以提高其運算速度。處理器內核的數量(Ncores)同樣會影響性能和成本。內存子系統的速度可以根據雙列直插內存模塊頻率(fDIMM)和匯流排頻率(fBus)進行參數化，它在工作負荷狀態下也對性能產生影響。同樣，電纜相互連接(interconnect fabric)的速度取決於信道點對點串列的頻率。
而其他一些因素，比如雙列直插內存模塊內存延遲(DIMM CAS Latency)，存儲信道的數量等都做為次要因素暫時忽略不計。
使用的性能參數
在圖示中標明的6個性能參數中，保留四個和模型相關的參數。
首先忽略信道點對點串列的頻率(fPCIe)，因為它主要影響的是電纜相互連接(interconnect fabric)速度的性能，這不在范圍之列。
接下來注意一下雙列直插內存模塊頻率(fDIMM)和匯流排頻率(fBus)會由於內存控制中心(MCH)而限於固定比率。
使用的雙核系統中，這些比率最具代表性的是4:5, 1:1, 5:4。一般情況下只會用到其中的一個。高速緩存存儲器的體積非常重要。
在這個模型中保留這個參數。內核的數量(Ncores)和內核頻率(fcore)也非常重要，保留這兩個參數。
高性能計算(HPC)模型
這第二個模型的基本形式在計算機體系研究領域已經存在了很多年。
A普通模式是：
(3) CPI = CPI0 + MPI * PPM
這里的CPI指的是處理器在工作負荷狀態下每執行一個指令的周期。CPI0是指內核CPI，MPI I則是指在工作負荷狀態下高速緩存存儲器每個指令失誤的次數(注釋：在高性能計算領域，MPI主要用於信息傳遞界面，在此處主要是指處理器構造慣例)，PPM是指以處理器時鍾滴答聲為單位對高速緩存存儲器每個指令失誤的次數的記錄。第二和第三個方程式相互吻合。這第一個術語代表的是處理器，第二個術語代表的是內存。
可以直觀的看到，假設每項工作下執行的P指令的工作負荷與代表處理器的頻率的內核頻率(每秒鍾處理器運行周期的單位)再與方程式(3)相乘，就得到了方程式(4):
Tnode = (CPIo * P) * (1 / fcore) + (MPI * P) * PPM * (1 / fcore)
在這里要注意(CPIo * P)是以每項工作分配下處理器的運行周期為單位，對微處理器架構上運行的既定工作負荷通常是個恆量。因此把它命名為α。(處理器周期本身無法對時間進行測算，如果乘以內核的頻率就可以得到時間的測算標准。因此Tnode在方程式(4)的右邊)。
(MPI * P)也是同理。對於既定工作負荷和體系結構來說它也是個恆量，但它主要依賴於高速緩存存儲器的體積。我們把它命名為M(MBcache)。而PPM是指訪問主存的成本。對於既定的工作負荷來說，通常是個固定的數字C。PPM乘以內存頻率和匯流排頻率的比值(fcore / fBus)就從匯流排周期(bus cycles)轉化成了處理器周期。因此PM = C * fcore / fBus。套入M(MBcache)就可以得到：
(5) Tnode = α * (1 / fcore) + M(MBcache) * (1 / fbus)
這個例子說明匯流排頻率(bus frequency)也是個恆量，方程式(5)可以簡化為方程式(6)：
(6) Tnode = α * (1 / fcore) + β
在這里Tcore = α * (1 / fcore)，而Tmemory = β(也就是公式2里的術語。我們把這些關鍵點關聯在一起)。
首先在模型2里，公式5和公式6都有堅實的理論基礎，因為經分析過它是如何從公式3推理而來(它主要應用於計算機體系理論)。其次，這個模型4個硬體性能參數的3個已經包括其中。還差一個參數就是內核數量(Ncores)。
用直觀的方式來說明內核的數量，就是假設把N個內核看做是一個網路頻率上運行的一個內核，稱之為N*fcore。那麼根據公式(6)我們大致可以推算出：
(7) Tcore ~ α / (N*fcore)
Tcore~ ( α / N) * (1 / fcore )
也可以把它寫成：
(8) αN = ( α / N)
多核處理器的第一個字母Alpha可能是單核處理器的1/N次。
通過數學推算這幾乎是完全可能的。
通常情況下我們是根據系統內核和匯流排頻率(bus frequencies)來衡量計算機系統性能，如公式(5)所闡述的。但是公式(5)的左邊是時間單位--這個時間單位指的是一項工作量的完成時間。這樣就能更清楚的以時間為單位說明右側的主系統參數。同時請注意內核的時鍾周期τcore(是指每次內核運行周期所需的時間)也等同於(1 / fcore)。匯流排時鍾(bus clock)周期也是同理。
(9) Tnode = αN * τcore + M(MBcache) * τBus
這個公式的轉化也給了一個完成時間的模型，那就是2個基本的自變數τcore和τBus呈現出直線性變化。這對使用一個簡單的棋盤式對照表對真實系統數據進行分析是有幫助的。

⑹ 生產級基於SpringCloud微服務架構性能優化實戰，建議收藏

本文將從 Tomcat性能優化，SpringCloud開啟重試機制，Zuul網關性能參數優化，Ribbon性能參數優化，Feign與Hystrix性能優化等 五個方面分享在生產環境如何做好SpringCloud性能優化。

一般基於SpringCloud的微服務能夠脫離傳統的tomcat，獨立跑起來，SpringBoot功不可沒，其原理是SpringBoot內嵌了tomcat（當然可以換成其他servlet容器，如jetty），能夠以java -jar形式就能跑起來。

所以針對每個springboot服務，我們需要對tomcat的一些參數進行優化，以下是樓主項目組優化的tomcat參數配置，供大家參考。

tomcat參數說明：

maxThreads，acceptCount參數應用場景

場景一

場景二

場景三

maxThreads調優

一般說伺服器性能要從兩個方面說起：

1、cpu計算型指標

2、io密集型指標

所以大部分情況下，tomcat處理io型請求比較多，比如常見的連資料庫查詢數據進行介面調用。

另外，要考慮tomcat的並發請求量大的情況下，對於伺服器系統參數優化，如虛擬機內存設置和linux的open file限制。

maxThreads設置多大合適？

我們知道線程過多，會導致cpu在線程切換時消耗的時間隨著線程數量的增加越來越大；線程太少，伺服器的請求響應吞吐量會急劇下降，所以maxThreads的配置絕對不是越大越好。

實際情況是設置maxThreads大小沒有最優解，要根據具體的伺服器配置，實際的應用場景不斷的調整和優化。

acceptCount設置多大合適？

盡量與maxThreads的大小保持一致 ， 這個值應該是主要根據應用的訪問峰值與平均值來權衡配置的。

當使用URL進行路由時，則需要對zuul.host.connect-timeout-millis和zuul.host.socket-timeout-millis參數控制超時時間。

請求連接的超時時間

請求處理的超時時間

對所有操作請求都進行重試

對當前實例的重試次數，針對同一個服務實例，最大重試次數（不包括首次調用）

對下個實例的重試次數，針同其它的服務實例，最大重試次數（不包括首次server）

注意Hystrix斷路器的超時時間需要大於ribbon的超時時間，不然不會觸發重試

Feign和Ribbon在整合了Hystrix後，首次調用失敗的問題？

目前樓主的強烈做法是： 禁用Hystrix的超時時間，設為false

還有一種是官方提倡的是 設置超時時間。

在實際的項目中親測，這種方式也有不好的地方， 如請求時間超過5s會出現請求數據時有時無的情況 ，給用戶的感覺是 系統不穩定，要求整改 。

另外，禁用hystrix，官方不推薦 。

hystrix超時設置原則

問題：一個http請求，如果feign和ribbon都配置了重試機制，異常情況下一共會請求多少次？

請求總次數 n 為feignClient和ribbon配置參數的笛卡爾積：

n(請求總次數) = feign(默認5次) * (MaxAutoRetries+1) * (MaxAutoRetriesNextServer+1)

其中+1是代表ribbon本身默認的請求。

其實二者的重試機制相互獨立，並無聯系。但是因為用了feign肯定會用到ribbon，所以feign的重試機制相對來說比較雞肋，一般會關閉該功能。ribbon的重試機制默認配置為0，也就是默認是去除重試機制的，建議不要修改。