提升nfd伺服器的讀性能

㈠ 如何優化RAID控制器提升存儲性能

許多參數都與緩存和緩存利用率，以及眾所周知的RAID
關於RAID級別與性能有關的文章已經很多，這里就不再重復了，主要談一下RAID的調優，如果你想通過配置RAID優化存儲性能，不管是安裝在PC伺服器上的RAID控制器，還是高端企業級存儲陣列，閱讀本文之後，你將有清晰的方向。
首先我們來看看RAID控制器的種類，目前我們常見的有以下三種：
1、企業級「Active/Active」：這種控制器允許你從任何主機向任何LUN寫入數據，不會造成性能下降，它通常具備很大的鏡像緩存(一般會超過32GB)，這種控制器支持熱插播硬碟，正常運行時間很長，現在與控制器通信一般是走光纖通道(FC)或乙太網光纖通道(FCoE)。
2、中端「主動/被動」：這種控制器對於每個LUN來說都有兩個側面，一個主動側面，它是主要路徑，一個被動側面，用於故障轉移，你通常需要在主要和故障轉移側之間分割LUN，平均劃分你的系統，緩存可以在控制器上鏡像，但這種控制器的彈性沒有企業級控制器好。
3、RAID主機卡：這種卡插入到PCIe插槽，通過SAS或SATA數據線連接到硬碟，它沒有獨立的處理器，而企業級和中端控制器都有，它們支持的硬碟數量也沒有前兩種控制器多，此外，要想故障轉移到另一個控制器也是不可能的，你系統的彈性完全取決於你的PCIe插槽和控制器卡。
RAID緩存調整和配置
可以從三個方面調整RAID緩存：
調整緩存，讀優先，寫在後。
調整緩存塊大小。
調整緩存鏡像(對於中端控制器來說特別重要)。
讀優先，寫在後：你可能會認為這樣調整後不會產生實質性效果，但事實證明不是你想像的那樣，如果讀優先，它會認為數據是連續的，這樣可以為數據分配連續的地址空間，RAID控制器不知道文件系統或數據的拓撲結構，它只知道連續塊地址。如果你的文件系統分配單元小於RAID條帶尺寸，如果同時有多個文件寫入，這些文件將會在這些RAID條帶上變成碎片。
例如，如果文件系統分配尺寸是64KB，RAID 5
8+1條帶大小是512KB，同時有多個文件寫入，RAID控制器做得最多的事情就是讀取你請求的數據，在這里是64KB，也可能是另一個64KB，如果你連續讀，直到讀完整個條帶，這就是讀優先，另一方面，如果你只讀一個64KB的塊，條帶中剩餘部分的數據來自其它文件，那麼讀優先只有害處，只有RAID條帶大小和文件系統分配單元相匹配時，實施讀優先才會獲得很好的性能。
寫在後：將塊讀入緩存以便寫入內容，當數據命中緩存時向寫入程序發送一個響應，這里的關鍵是數據在RAID條帶上必須是對齊的，如果沒有對齊，RAID必須完成「讀-修改-寫入」(讀入條帶數據，修改成新數據，再寫入條帶)，這樣的後果是開銷大，延遲嚴重，RAID緩存的目的本來就是為了隱藏寫入磁碟的延遲，當數據命中緩存時接收確認。調整寫在後通常需要針對讀優先指定需要分配多少緩存空間，此外還需要指定可讀或寫的最小緩存塊大小。
調整RAID緩存塊大小
緩存塊大小是可以讀入緩存的最小數據量，例如，在一塊磁碟上的一個RAID分配單元可能是32KB，你可能會認為該磁碟的所有I/O單元都是32KB，但如果緩存塊大小是4KB，那對該磁碟的最小讀或寫大小應該是4KB，而不是32KB，它是今天磁碟扇區大小的8倍，如果你的文件系統分配單元很大，你的寫入請求也很大，但緩存塊大小很小，就可能會降低RAID的性能。
我所見過的大多數RAID控制器都是這樣，緩存塊越小速度越慢，因為它們沒有足夠的處理器能力管理所有的塊，也許等下一代控制器上市會改變這一現狀(因為處理性能將會提升)。只有在RAID分配單元中數據處於非對齊狀態時，緩存塊小一點更好。
想像一下以小的請求寫，大的請求讀，文件系統分配單元和條帶大小匹配時會是什麼狀況，發生多個連續寫操作時，文件系統不會產生嚴重的碎片，並且讀優先將會起作用，如果讀比寫更大，讀優先也有幫助，所有RAID控制器會認為讀是連續的，因此在調整讀操作時，你需要知道讀和寫請求大小，並確定同一時間有多少文件寫入，如果同一時間只有一個文件寫入，數據將很可能是連續分配的，直到文件系統產生碎片，讀優先將會帶來很大的好處。
另一方面，如果有多個文件寫入，並且寫入大小和文件系統分配單元比條帶尺寸小，這時讀優先的作用就很小，甚至毫無作用。歸結起來就是：讀優先適用於寫和分配單元相等，或者當有多個文件寫入時，大於RAID的條帶尺寸。
調整緩存鏡像
在許多中端RAID產品中，寫緩存鏡像是一個常見的功能，所有寫入內容全部鏡像到RAID控制器中，控制器處理I/O請求，將其寫入控制器的另一半緩存中，如果數據在條帶上是完全對齊的，有些廠商在控制器上使用一些技術繞過緩存寫入請求，但在普通環境中是具有寫緩存鏡像的，每一次寫操作都要寫入到緩存，在向I/O請求發出確認前再寫入到另一個緩存，寫緩存鏡像因此通常會降低性能，因為寫入其它緩存存在延遲，並會佔用一定的帶寬，每個緩存必須鏡像到其它緩存，因此緩存空間利用率會下降一半。
如果廠商提供了讀或寫緩存調整參數，可以根據負載和可靠性考慮進行微調。我經常聽到的一個問題是用戶到底應不應該使用寫緩存鏡像，這要根據你對數據可靠性的需要而定。假設你正在寫一個文件，將數據寫入一個沒有寫緩存鏡像系統的緩存，如果這個時候整個控制器出現故障(從緩存到磁碟)，你的應用程序會被告知寫入成功，但數據卻沒有來得及寫入磁碟。雖然這種事故發生的幾率非常小，但仍然是可能發生的，我就有幸見過一次。
如果你對同一個文件再執行一個寫入操作，你可能會遭遇I/O錯誤，大多數RAID這個時候會意識到它們不能從緩存寫入到磁碟，因此會暴露錯誤，有的RAID控制器會故障轉移到可以工作的一側，你的操作得以成功完成，但實際上已經有一個文件已經丟失了，但你的應用程序卻不知道，如果文件少寫入了內容，這可能會引發後續一系列的連鎖反應，這也是為什麼寫緩存鏡像默認啟用的原因。調整寫緩存鏡像需要指定為寫入操作保留多少緩存空間，寫緩存鏡像開關應該開啟，如果控制器損壞，想要找出損壞的數據或缺少的數據幾乎是不可能的。
其實只要掌握一點RAID控制器的常識，調整它就不難了。我們需要記住的是，如果同時有多個文件寫入，文件系統分配單元很小時，讀優先是沒有用的，最糟糕的一個例子就是Windows上的NTFS。

㈡ 伺服器性能不足怎麼辦

升級伺服器 或者減少程序代碼的運行

㈢ 怎樣提高IIS伺服器性能，加快伺服器速度

1、應該分配和釋放多個對象

你應該盡量避免過量分配內存，因為內存分配可能是代價高昂的。釋放內存塊可能更昂貴，因為大多數分配算符總是企圖連接臨近的已釋放的內存塊成為更大的塊。直到Windows NT? 4.0 service pack 4.0，在多線程處理中，系統堆通常都運行得很糟。堆被一個全局鎖保護，並且在多處理器系統上是不可擴展的。

2.不應該考慮使用處理器高速緩存

大多數人都知道由虛擬內存子系統導致的hard 頁錯誤代價很高，最好避免。但是許多人認為其他內存訪問方法沒有什麼區別。自從80486以後，這一觀點就不對了。現代的CPUs比RAM要快得多，RAM至少需要兩級內存緩存 ，高速L1 緩存能保存8KB數據和8KB指令，而較慢的L2 緩存能保存幾百KB的數據和代碼，這些數據和代碼混合在一起。L1 緩存中內存區域的一個引用需要一個時鍾周期，L2 緩存的引用需要4到7個時鍾周期，而主內存的引用需要許多個處理器時鍾周期。後一數字不久將會超過100個時鍾周期。在許多方面，緩存像一個小型的，高速的，虛擬內存系統。

至於和緩存有關的基本內存單元不是位元組而是緩存列。Pentium 緩存列有32個位元組寬。Alpha 緩存列有64個位元組寬。這意味著在L1 緩存中只有512個slot給代碼和數據。如果多個數據一起使用（時間位置）而並不存儲在一起（空間位置），性能會很差。數組的空間位置很好，而相互連接的列表和其他基於指針的數據結構的位置往往很差。

把數據打包到同一個緩存列中通常會有利於提高性能，但是它也會破壞多處理器系統的性能。內存子系統很難協調處理器間的緩存。如果一個被所有處理器使用的只讀數據，和一個由一個處理器使用並頻繁更新的數據共享一個緩存 列，那麼緩存將會花費很長時間更新這個緩存列的拷貝。這個Ping-Pong高速游戲通常被稱為"緩存 sloshing"。如果只讀數據在一個不同的緩存 列中，就可以避免sloshing。

對代碼進行空間優化比進行速度優化效率更高。代碼越少，代碼所佔的頁也越少，這樣需要的運行設置和產生的頁錯誤也會更少，同時占據的緩存 列也會更少。然而，某些核心函數應該進行速度優化。可以利用profiler去識別這些函數。

3.決不要緩存頻繁使用的數據。

軟體緩存可以被各種應用程序使用。當一個計算代價很高時，你會保存結果的一個拷貝。這是一個典型的時空折中方法：犧牲一些存儲空間以節省時間。如果做得好，這種方法可能非常有效。

你必須正確地進行緩存。如果緩存了錯誤數據，就會浪費存儲空間。如果緩存得太多，其他操作可以使用的內存將會很少。如果緩存得太少，效率又會很低，因為你必須重新計算被緩存 遺漏的數據。如果將時間敏感數據緩存得時間過長，這些數據將會過時。一般，伺服器更關心的是速度而不是空間，所以他們要比桌面系統進行更多的緩存。一定要定期去除不用的緩存，否則將會有運行設置問題。

4.應該創建多個線程，越多越好。

調整伺服器中起作用的線程數目是很重要的。如果線程是I/O-bound的，將會花費很多時間用來等待I/O的完成-一個被阻塞的線程就是一個不做任何有用工作的線程。加入額外的線程可以增加通量，但是加入過多的線程將會降低伺服器的性能，因為上下文交換將會成為一個重大的overhead。上下文交換速度應該低的原因有三個：上下文交換是單純的overhead，對應用程序的工作沒有任何益處；上下文交換用盡了寶貴的時鍾周期；最糟的是，上下文交換將處理器的緩存填滿了沒用的數據，替換這些數據是代價高昂的。

有很多事情是依靠你的線程化結構的。每個客戶端一個線程是絕對不合適的。因為對於大量用戶端，它的擴展性不好。上下文交換變得難以忍受，Windows NT用盡了資源。線程池模型會工作得更好，在這種方法中一個工人線程池將處理一條請求列，因為Windows 2000提供了相應的APIs，如QueueUserWorkItem。

5.應該對數據結構使用全局鎖

使數據線程安全的最簡單方法是把它套上一把大鎖。為簡單起見，所有的東西都用同一把鎖。這種方法會有一個問題：序列化。為了得到鎖，每一個要處理數據的線程都必須排隊等候。如果線程被一把鎖阻塞，它沒有在做任何有用的事。當伺服器的負載較輕時，這個問題並不常見，因為一次可能只有一個線程需要鎖。在負載很重的情況下，對鎖的激烈爭奪可能就會成為一個大問題。

設想在多車道高速公路上發生了一個意外事故，這條高速公路上的所有車輛都被轉向一條狹窄的道路。如果車輛很少，這一轉換對交通流的速率的影響可以忽略。如果車輛很多，當車輛慢慢並入那條單通道時，交通阻塞會延伸幾英里。

有幾種技術能夠減少鎖競爭。

· 不要過分保護，也就是說，不是非常必要不要鎖住數據。只有需要時才去持有鎖，而且時間不要過長。不要在大段代碼周圍或頻繁執行的代碼中沒必要地使用鎖，這一點很重要。

· 對數據進行分割，使它能夠用一套獨立的鎖保護。例如，一個符號表可以按標識符的第一個字母分割，這樣在修改名字以Q開頭的符號的值時，就不會去讀名字以H開頭的符號的值。

· 使用APIs的Interlocked 系列（InterlockedIncrement，等）自動修改數據而不需要鎖。

· 當數據不是經常被修改時可以使用多讀者/單作者（multi-reader/single-writer）鎖。你將獲得更好的並發性，盡管鎖操作的代價將更高並且你可能會冒餓死作者的危險。

· 在關鍵部分使用循環計數器。參見Windows NT 4.0 service pack 3中的SetCriticalSectionSpinCount API。

· 如果你不能得到鎖，使用TryEnterCriticalSection並做一些其他的有用的工作。

高競爭導致serialization，serialization導致降低CPU的利用率，這促使用戶加入更多的線程，結果事情變得更糟。

6.不必注意多處理器機器

你的代碼在多處理器系統上比在單處理器系統上運行得還要糟，這可能是件令人惡心的事。一個很自然的想法是，在一個N維系統上運行N次會更好。性能很差的原因是競爭：鎖競爭，匯流排競爭，和/或緩存列競爭。處理器都在是爭奪共享資源的所有權，而不是做更多的工作。

如果你一定要編寫多線程應用程序的話，你應該在多處理器盒上對你的應用程序進行強度測試和性能測試。單處理器系統通過時間分片地執行線程而提供一個並發性的假象。多處理器盒具有真正的並發性，競爭環境和競爭更容易發生。

7.應該始終使用模塊化調用；他們很有趣。

利用同步模塊化調用來執行I/O操作對大多數桌面應用程序來說是合適的。但是，他們不是使用伺服器上的CPU（s）的好方法。I/O操作要花費上百萬個時鍾周期來完成，這些時鍾周期本來可以被更好地利用。利用非同步I/O你能得到顯著提高的用戶請求率和I/O通量，不過增加了額外的復雜性。

如果你有需要花費很長時間的模塊化調用或I/O操作，你應該考調撥多少資源給他們。你想使用所有的線程還是有個限制？一般地，使用有限的幾個線程要好些。構建一個小的線程池和隊列，利用隊列來安排線程的工作完成模塊化調用。這樣，其他線程就可以拾取和處理你的非模塊化的請求。

8.不要進行測量

當你能夠測量你所談論的事情並用數字表達它時，這就表示你對他有了一定的了解；但是如果你不能用數字表達時，你的知識是貧瘠的不能令人滿意的；這可能是知識的開始，但這時你簡直不可能將你的思想提高到科學的水平。

- Lord Kelvin (William Thomson)

如果不測量你就不能了解應用程序的特性。你在黑暗中摸索，一半是靠猜測。如果不識別性能問題，你就不能做任何改進或做出工作量計劃。

測量包括黑匣子測量和profiling。黑匣子測量的意思是收集由性能計數器（內存使用，上下文交換，CPU利用等）和外部檢測工具（通量，反映時間等）所顯示的數據。為了profile你的代碼，你編譯代碼的一個工具版，然後在各種條件下運行它，並收集關於執行時間和過程調用頻率的統計數據。

測量如果不用於分析的話就一點用都沒有。測量將不僅告訴你有問題，而且甚至能幫助你找到問題發生在哪，但它不能告訴你為什麼會有問題。對問題進行分析以便你能正確地改正他們。要從根本上解決問題而不是停留在表面現象。

當你進行改動後，要重新測量。你要知道你的改動是否有效。改動也可能會暴露其他性能問題，測量-分析-改正-再測量的循環就會重新開始。你也必須要有規律地進行測量，以便發現性能衰退問題。

9.應該使用單一用戶，單一請求的測試方法。

書寫ASP和ISAPI應用程序的一個通病是只用一個瀏覽器去測試應用程序。當他們在Internet上應用他們的程序時，他們才發現他們的應用程序不能處理高負載，並且通量和反應時間另人可憐。

用一個瀏覽器測試是必要的但是不夠的。如果瀏覽器反應得不夠快，你就知道你有麻煩了。但即使它在使用一個瀏覽器時很快，你也不知道它處理負載的能力如何。如果十幾個用戶同時請求會發生什麼事？一百個呢？你的應用程序能容忍什麼樣的通量？它能提供什麼樣的反應時間？在輕載時這些數字會怎樣？中等負載呢？重載呢？在多處理器機器上你的應用程序會如何？對你的應用程序進行強度測試，這對於找出bugs發現性能問題來說是基本的。

類似的負載測試考慮適用於所有的伺服器應用程序。

10.不應使用實際環境。

人們往往只在幾個特定的，人工的環境（如下benchmarks）下調整應用程序。選擇和實際情況相對應的各種情況，並為針對各種操作進行優化，這一點很重要。如果你不這樣做，你的用戶和評論家一定會這樣做，並且他們將依此來評判你的應用程序的好壞。

㈣ 如何利用Nginx的緩沖，緩存優化提升性能

反向代理的一個問題是代理大量用戶時會增加伺服器進程的性能沖擊影響。在大多數情況下，可以很大程度上能通過利用Nginx的緩沖和緩存功能減輕。
當代理到另一台伺服器，兩個不同的連接速度會影響客戶的體驗：
從客戶機到Nginx代理的連接。
從Nginx代理到後端伺服器的連接。
Nginx具有優化這些連接調整其行為的能力。
如果沒有緩沖，數據從代理的伺服器發送並立即開始被發送到客戶。如果假定客戶端很快，緩沖可以關閉而盡快使數據到客戶端，有了緩沖，Nginx 代理將暫時存儲後端的響應，然後按需供給數據給客戶端。如果客戶端是緩慢的，允許Nginx伺服器關閉到後端的連接。然後，它可以處理數據分配到客戶端， 以任何可能的速度。
Nginx默認有緩沖設計，因為客戶端往往有很大的不同的連接速度。我們可以用以下指令調節緩沖行為。可以在HTTP，server或 location位置來設置。重要的是要記住，大小size指令是針對每個請求配置的，所以增加超出你需求會影響你的性能，如果這時有許多客戶端請求：
proxy_buffering：該指令控制緩沖是否啟用。默認情況下，它的值是「on」。
proxy_buffers：該指令控制代理響應緩沖區的數量（第一個參數）和大小（第二個參數）。默認配置是8個緩沖區大小等於一個內存頁（4K或者8K）。增加緩沖區的數目可以讓你緩沖更多信息。
proxy_buffer_size：從後端伺服器的響應頭緩沖區大小，它包含headers，和其他部分響應是分開的。該指令設置響應部分的緩沖區大小。默認情況下，它和proxy_buffers是相同的尺寸，但因為這是用於頭信息，這通常可以設置為一個較低的值。
proxy_busy_buffers_size：此指令設置標注「client-ready」緩沖區的最大尺寸。而客戶端可以一次讀取來自一個緩沖區的數據，緩沖被放置在隊列中，批量發送到客戶端。此指令控制允許是在這種狀態下的緩沖空間的大小。
proxy_max_temp_file_size：這是每個請求能用磁碟上臨時文件最大大小。這些當上游響應太大不能裝配到緩沖區時被創建。
proxy_temp_file_write_size：這是當被代理伺服器的響應過大時Nginx一次性寫入臨時文件的數據量。
proxy_temp_path：當上游伺服器的響應過大不能存儲到配置的緩沖區域時，Nginx存儲臨時文件硬碟路徑。
正如你所看到的，Nginx提供了相當多的不同的指令來調整緩沖行為。大多數時候，你不必擔心太多，但它對於調整一些值可能是有用的。可能最有用的調整是proxy_buffers和proxy_buffer_size指令。

㈤ linux怎樣提升磁碟讀寫性能

關於頁面緩存的信息，可以用
cat /proc/meminfo
看到。其中的Cached 指用於pagecache的內存大小（diskcache-SwapCache）。隨著寫入緩存頁，Dirty 的值會增加。
一旦開始把緩存頁寫入硬碟,Writeback的值會增加直到寫入結束。

Linux 用pdflush進程把數據從緩存頁寫入硬碟，查看有多少個pdflush進程
cat /proc/sys/vm/nr_pdflush_threads

pdflush的行為受/proc/sys/vm中的參數的控制
/proc/sys/vm/dirty_writeback_centisecs (default 500):
1/100秒, 多長時間喚醒pdflush將緩存頁數據寫入硬碟。默認5秒喚醒2個（更多個）線程。
如果wrteback的時間長於dirty_writeback_centisecs的時間，可能會出問題。

pdflush的第一件事是讀取
/proc/sys/vm/dirty_expire_centiseconds (default 3000)
1/100秒。緩存頁里數據的過期時間(舊數據)，在下一個周期內被寫入硬碟。默認30秒是一個很長的時間。

第二件事是判斷內存是否到了要寫入硬碟的限額，由參數決定：
/proc/sys/vm/dirty_background_ratio (default 10)
百分值，保留過期頁緩存（臟頁緩存）的最大值。是以MmeFree+Cached-Mapped的值為基準的

pdflush寫入硬碟看兩個參數：
1 數據在頁緩存中是否超出30秒，如果是，標記為臟頁緩存;
2 臟頁緩存是否達到工作內存的10%;

以下參數也會影響到pdflush
/proc/sys/vm/dirty_ratio (default 40)
總內存的最大百分比，系統所能擁有的最大臟頁緩存的總量。超過這個值，開啟pdflush寫入硬碟。如果cache增長快於pdflush，那麼整個系統在40%的時候遇到I/O瓶頸，所有的I/O都要等待cache被pdflush進硬碟後才能重新開始。

對於有高度寫入操作的系統
dirty_background_ratio: 主要調整參數。如果需要把緩存持續的而不是一下子大量的寫入硬碟，降低這個值。
dirty_ratio： 第二調整參數。

Swapping參數
/proc/sys/vm/swappiness
默認，linux傾向於從物理內存映射到硬碟緩存，保持硬碟緩存盡可能大。未用的頁緩存會被放進swap區。
數值為0，將會避免使用swapping
100，將會盡量使用swapping
少用swapping會增加程序的響應速度；多用swapping將會提高系統的可用性。

如果有大量的寫操作，為避免I/O的長時間等待，可以設置：
$ echo 5 > /proc/sys/vm/dirty_background_ratio
$ echo 10 > /proc/sys/vm/dirty_ratio

文件系統數據緩沖需要頻繁的內存分配。加大保留內存的值能提升系統速度和穩定。小於8G的內存，保留內存為64M，大於8G的設置為256M
$ echo 65536 > /proc/sys/vm/min_free_kbytes


I/O 調度器
cat /sys/block/[disk]/queue/scheler

4中調度演算法
noop anticipatory deadline [cfq]
deadline : deadline 演算法保證對既定的IO請求以最小的延遲時間。
anticipatory： 有個IO發生後，如果又有進程請求IO，則產生一個默認6ms猜測時間，猜測下一個進程請求IO是干什麼。這對於隨機讀取會造成較大的延時。
對資料庫應用很糟糕，而對於Web Server等則會表現不錯。
cfq: 對每個進程維護一個IO隊列，各個進程發來的IO請求會被cfq以輪循方式處理，對每一個IO請求都是公平。適合離散讀的應用。
noop: 對所有IO請求都用FIFO隊列形式處理。默認IO不會存在性能問題。

改變調度器
$ echo deadline > /sys/block/sdX/queue/scheler
對於資料庫伺服器，deadline演算法是推薦的。

提高調度器請求隊列的
$ echo 4096 > /sys/block/sdX/queue/nr_requests

有大量的讀請求，默認的請求隊列應付不過來，可以提高這個值。缺點是要犧牲一定的內存。
為了增加連續讀取的吞吐量，可以增加預讀數據量。預讀的實際值是自適應的，所以使用一個較高的值，不會降低小型隨機存取的性能。
$ echo 4096 > /sys/block/sdX/queue/read_ahead_kb
如果LINUX判斷一個進程在順序讀取文件，那麼它會提前讀取進程所需文件的數據，放在緩存中。伺服器遇到磁碟寫活動高峰，導致請求處理延遲非常大（超過3秒）。通過調整內核參數，將寫活動的高峰分布成頻繁的多次寫，每次寫入的數據比較少。這樣可以把尖峰的寫操作削平成多次寫操作。以這種方式執行的效率比較低，因為內核不太有機會組合寫操作。但對於繁忙的伺服器，寫操作將更一致地進行，並將極大地改進互動式性能。

/proc/sys/vm/dirty_ratio

控制文件系統的寫緩沖區的大小，單位是百分比，表示占系統內存的百分比，表示當寫緩沖使用到系統內存多少的時候，開始向磁碟寫出數據。增大之會使用更多系統內存用於磁碟寫緩沖，也可以極大提高系統的寫性能。但是，當你需要持續、恆定的寫入場合時，應該降低其數值。

/proc/sys/vm/dirty_background_ratio

控制文件系統的pdflush進程，在何時刷新磁碟。單位是百分比，表示系統內存的百分比，pdflush用於將內存中的內容和文件系統進行同步，比如說,當一個文件在內存中進行修改,pdflush負責將它寫回硬碟.每當內存中的垃圾頁（dirty page）超過10%的時候,pdflush就會將這些頁面備份回硬碟.增大之會使用更多系統內存用於磁碟寫緩沖，也可以極大提高系統的寫性能。但是，當你需要持續、恆定的寫入場合時，應該降低其數值：

/proc/sys/vm/dirty_writeback_centisecs

控制內核的臟數據刷新進程pdflush的運行間隔。單位是 1/100 秒。預設數值是500，也就是 5 秒。如果你的系統是持續地寫入動作，那麼實際上還是降低這個數值比較好，這樣可以把尖峰的寫操作削平成多次寫操作。
如果你的系統是短期地尖峰式的寫操作，並且寫入數據不大（幾十M/次）且內存有比較多富裕，那麼應該增大此數值。
該參數的設置應該小於dirty_expire_centisecs，但也不能太小，太小I/O太頻繁，反而
使系統性能下降。具體可能需要在生產環境上測試。據說1:6 (dirty_expire_centisecs : dirty_writeback_centisecs )的比例比較好。

/proc/sys/vm/dirty_expire_centisecs

聲明Linux內核寫緩沖區裡面的數據多「舊」了之後，pdflush進程就開始考慮寫到磁碟中去。單位是 1/100秒。預設是 30000，也就是 30 秒的數據就算舊了，將會刷新磁碟。對於特別重載的寫操作來說，這個值適當縮小也是好的，但也不能縮小太多，因為縮小太多也會導致IO提高太快。
當然，如果你的系統內存比較大，並且寫入模式是間歇式的，並且每次寫入的數據不大（比如幾十M），那麼這個值還是大些的好。

/proc/sys/vm/vfs_cache_pressure

表示內核回收用於directory和inode cache內存的傾向；預設值100表示內核將根據pagecache和swapcache，把directory和inode cache保持在一個合理的百分比；降低該值低於100，將導致內核傾向於保留directory和inode cache；增加該值超過100，將導致內核傾向於回收directory和inode cache

/proc/sys/vm/min_free_kbytes

表示強制Linux VM最低保留多少空閑內存（Kbytes）。
預設設置：724（512M物理內存）

/proc/sys/vm/nr_pdflush_threads

表示當前正在運行的pdflush進程數量，在I/O負載高的情況下，內核會自動增加更多的pdflush進程。

/proc/sys/vm/overcommit_memory

指定了內核針對內存分配的策略，其值可以是0、1、2。

0， 表示內核將檢查是否有足夠的可用內存供應用進程使用；如果有足夠的可用內存，內存申請允許；否則，內存申請失敗，並把錯誤返回給應用進程。

1， 表示內核允許分配所有的物理內存，而不管當前的內存狀態如何。

2， 表示內核允許分配超過所有物理內存和交換空間總和的內存（參照overcommit_ratio）。

預設設置：0

/proc/sys/vm/overcommit_ratio

如果overcommit_memory=2，可以過載內存的百分比，通過以下公式來計算系統整體可用內存。系統可分配內存=交換空間+物理內存*overcommit_ratio/100
預設設置：50（%）

/proc/sys/vm/page-cluster

表示在寫一次到swap區的時候寫入的頁面數量，0表示1頁，1表示2頁，2表示4頁。
預設設置：3（2的3次方，8頁）

/proc/sys/vm/swapiness

表示系統進行交換行為的程度，數值（0-100）越高，越可能發生磁碟交換。

更改：
/etc/sysctl.conf

vm.dirty_ratio=40

sysctl -p

查看：

find /proc/sys/vm -name dirty* -print | while read name; do echo $name ;cat ${name}; done

㈥ 影響伺服器性能的四個主要因素

一、處理器CPU

不管是國內伺服器，還是海外伺服器，它的處理器是非常重要的。就像電腦的CPU一樣，這個是處理所有運算的大腦，如果沒有CPU，或者CPU的配置不夠好，運行1，2個項目就可能導致伺服器宕機。

二、選擇合適的內存

一般來說，伺服器性能也取決於內存的大小。我們知道，內存的大小決定一個伺服器能同時啟用多少個應用程序，普通的伺服器一般是4G-32G之間，對於一些高端的伺服器，內存可以擴展到64GB，甚至更高。不過一般的網站伺服器普通的內存大小即可，如果內存大小實在不夠，可以進行擴容。

三、選擇合適的硬碟類型

硬碟也有不同的類型，比如選擇固態硬碟SSD，或者HDD硬碟，HDD整體上來說讀取速度會比SSD要慢很多，但是價格相對來說會便宜很多，看企業的預算成本 。

四、磁碟陣列

不同的磁碟類型對數據的存儲性能及可靠性也是有很大差別的，一般入門級伺服器配備RAID 0或1即可，高一點配置的可以考慮RAID5 或者 RAID 10。一般來說RAID是比較常見的，尤其是Windows操作系統伺服器，軟體在RAID中也更受歡迎。

㈦ DDR5來了，新的內存技術對電腦性能提升有多大幫助

首先DDR5內存最先還是會在伺服器上應用，而不是民用市場，短時間內DDR5內存並不會普及，所以如今夠買DDR4內存仍然不算晚。

而且電腦硬體的普及需要的時間是極其漫長的，如今很多用戶的電腦仍然還是DDR3內存，甚至還有DDR2的老爺機。所以就算新的內存可以提升性能，對於個人用戶來說也是有些遙遠的事。

但更高頻的內存也有好處，比如游戲開發商在開發游戲時，需要在游戲優化上下的功夫就少了，能進一步拉近大廠游戲和小作坊游戲在優化層面上的差距。對於一些專業用戶，比如特效、剪輯為主的電腦用戶，高頻的內存也可以帶來更好的工作體驗。只是這個體驗的提升遠遠沒有想像中的大。

㈧ 如何提高Linux伺服器磁碟io性能

您好，很高興為您解答。

在現有文件系統下進行優化：
linux內核和各個文件系統採用了幾個優化方案來提升磁碟訪問速度。但這些優化方案需要在我們的伺服器設計中進行配合才能得到充分發揮。
文件系統緩存
linux內核會將大部分空閑內存交給虛擬文件系統，來作為文件緩存，叫做page cache。在內存不足時，這部分內存會採用lru演算法進行淘汰。通過free命令查看內存，顯示為cached的部分就是文件緩存了。

如何針對性優化：
lru並不是一個優秀淘汰演算法，lru最大的優勢是普適性好，在各種使用場景下都能起到一定的效果。如果能找到當前使用場景下，文件被訪問的統計特徵，針 對性的寫一個淘汰演算法，可以大幅提升文件緩存的命中率。對於http正向代理來說，一個好的淘汰演算法可以用1GB內存達到lru演算法100GB內存的緩存 效果。如果不打算寫一個新的淘汰演算法，一般不需要在應用層再搭一個文件cache程序來做緩存。

最小分配：
當文件擴大，需要分配磁碟空間時，大部分文件系統不會僅僅只分配當前需要的磁碟空間，而是會多分配一些磁碟空間。這樣下次文件擴大時就可以使用已經分配好的空間，而不會頻繁的去分配新空間。
例如ext3下，每次分配磁碟空間時，最小是分配8KB。
最小分配的副作用是會浪費一些磁碟空間（分配了但是又沒有使用）

如何針對性優化：
我們在reiserfs下將最小分配空間從8KB改大到128K後提升了30%的磁碟io性能。如果當前使用場景下小文件很多，把預分配改大就會浪費很多 磁碟空間，所以這個數值要根據當前使用場景來設定。似乎要直接改源代碼才能生效，不太記得了，09年的時候改的，有興趣的同學自己google吧。

io訪問調度：
在同時有多個io訪問時，linux內核可以對這些io訪問按LBA進行合並和排序，這樣磁頭在移動時，可以「順便」讀出移動過程中的數據。
SATA等磁碟甚至在磁碟中內置了io排序來進一步提升性能，一般需要在主板中進行配置才能啟動磁碟內置io排序。linux的io排序是根據LBA進行的，但LBA是一個一維線性地址，無法完全反應出二維的圓形磁碟，所以磁碟的內置io排序能達到更好的效果。

如何針對性優化：
io訪問調度能大幅提升io性能，前提是應用層同時發起了足夠的io訪問供linux去調度。
怎樣才能從應用層同時向內核發起多個io訪問呢？
方案一是用aio_read非同步發起多個文件讀寫請求。
方案二是使用磁碟線程池同時發起多個文件讀寫請求。
對我們的http正向代理來說，採用16個線程讀寫磁碟可以將性能提升到2.5倍左右。具體開多少個線程/進程，可以根據具體使用場景來決定。

小提示：
將文件句柄設置為非阻塞時，進程還是會睡眠等待磁碟io，非阻塞對於文件讀寫是不生效的。在正常情況下，讀文件只會引入十幾毫秒睡眠，所以不太明顯；而在磁碟io極大時，讀文件會引起十秒以上的進程睡眠。

預讀取：
linux內核可以預測我們「將來的讀請求」並提前將數據讀取出來。通過預讀取可以減少讀io的次數，並且減小讀請求的延時。

如何針對性優化：
預讀取的預測准確率是有限的，與其依賴預讀取，不如我們直接開一個較大的緩沖區，一次性將文件讀出來再慢慢處理；盡量不要開一個較小的緩沖區，循環讀文件/處理文件。
雖然說「預讀取」和「延遲分配」能起到類似的作用，但是我們自己擴大讀寫緩沖區效果要更好。

延遲分配：
當文件擴大，需要分配磁碟空間時，可以不立即進行分配，而是暫存在內存中，將多次分配磁碟空間的請求聚合在一起後，再進行一次性分配。
延遲分配的目的也是減少分配次數，從而減少文件不連續。

延遲分配的副作用有幾個：
1、如果應用程序每次寫數據後都通過fsync等介面進行強制刷新，延遲分配將不起作用
2、延遲分配有可能間歇性引入一個較大的磁碟IO延時（因為要一次性向磁碟寫入較多數據）
只有少數新文件系統支持這個特性

如何針對性優化：
如果不是對安全性（是否允許丟失）要求極高的數據，可以直接在應用程序里緩存起來，積累到一定大小再寫入，效果比文件系統的延遲分配更好。如果對安全性要求極高，建議經常用fsync強制刷新。

在線磁碟碎片整理：
Ext4提供了一款碎片整理工具，叫e4defrag，主要包含三個功能：
1、讓每個文件連續存儲
2、盡量讓每個目錄下的文件連續存儲
3、通過整理空閑磁碟空間，讓接下來的分配更不容易產生碎片

如何針對性優化：
「讓每個目錄下的文件連續存儲」是一個極有價值的功能。
傳統的做法是通過拼接圖片來將這10張圖片合並到一張大圖中，再由前端將大圖切成10張小圖。
有了e4defrag後，可以將需連續訪問的文件放在同一個文件夾下，再定期使用e4defrag進行磁碟整理。

實現自己的文件系統：
在大部分伺服器上，不需要支持「修改文件」這個功能。一旦文件創建好，就不能再做修改操作，只支持讀取和刪除。在這個前提下，我們可以消滅所有文件碎片，把磁碟io效率提升到理論極限。

有一個公式可以衡量磁碟io的效率：
磁碟利用率 = 傳輸時間/（平均尋道時間+傳輸時間）

如若滿意，請點擊回答右側【採納答案】，如若還有問題，請點擊【追問】

~ O(∩_∩)O~

㈨ 如何進行全面提高FTP伺服器的安全性能呢

Windows2000系統提供了FTP服務功能，由於簡單易用，伺服器託管與Windows系統本身結合緊密，深受廣大用戶的喜愛。但使用IIS5.0 架設的FTP伺服器真的安全嗎？它的默認設置其實存在很多安全隱患，很容易成為黑客們的攻擊目標。伺服器託管如何讓FTP伺服器更加安全，只要稍加改造，就能做到。

一 取消匿名訪問功能

默認情況下伺服器託管，Windows2000系統的FTP伺服器是允許匿名訪問的，雖然匿名訪問為用戶上傳、下載文件提供方便，但卻存在極大的安全隱患。用戶不需要申請合法的賬號，就能訪問FTP伺服器，甚至還可以上傳、下載文件，特別對於一些存儲重要資料的FTP伺服器，伺服器託管很容易出現泄密的情況，因此建議用戶取消匿名訪問功能。

在Windows2000系統中，點擊「開始→程序→管理工具→Internet服務管理器」，彈出管理控制台窗口。然後展開窗口左側的本地計算機選項，就能看到IIS5.0自帶的FTP伺服器，下面筆者以默認FTP站點為例，介紹如何取消匿名訪問功能。

右鍵點擊「默認FTP站點」項，在右鍵菜單中選擇「屬性」，伺服器託管接著彈出默認FTP站點屬性對話框，切換到「安全賬號」標簽頁，取消「允許匿名連接」前的勾選，最後點擊「確定」按鈕，這樣用戶就不能使用匿名賬號訪問FTP伺服器了，必須擁有合法賬號。

二 啟用日誌記錄

Windows日誌記錄著系統運行的一切信息，但很多管理員對日誌記錄功能不夠重視，為了節省伺服器資源，禁用了FTP伺服器日誌記錄功能，伺服器託管這是萬萬要不得的。FTP伺服器日誌記錄著所有用戶的訪問信息，如訪問時間、客戶機IP地址、使用的登錄賬號等，這些信息對於FTP伺服器的穩定運行具有很重要的意義，一旦伺服器出現問題，就可以查看FTP日誌，找到故障所在，及時排除。因此一定要啟用FTP日誌記錄。

在默認FTP站點屬性對話框中，切換到「FTP站點」標簽頁，一定要確保「啟用日誌記錄」選項被選中，這樣就可以在「事件查看器」中查看FTP日誌記錄了。

三 正確設置用戶訪問許可權

每個FTP用戶賬號都具有一定的訪問許可權，但對用戶許可權的不合理設置，也能導致FTP伺服器出現安全隱患。如伺服器中的CCE文件夾，只允許 CCEUSER賬號對它有讀、寫、修改、列表的許可權，禁止其他用戶訪問，但系統默認設置，還是允許其他用戶對CCE文件夾有讀和列表的許可權，伺服器託管因此必須重新設置該文件夾的用戶訪問許可權。

右鍵點擊CCE文件夾，在彈出菜單中選擇「屬性」，然後切換到「安全」標簽頁，首先刪除Everyone用戶賬號，接著點擊「添加」按鈕，伺服器託管將 CCEUSER賬號添加到名稱列表框中，然後在「許可權」列表框中選中修改、讀取及運行、列出文件夾目錄、讀取和寫入選項，最後點擊「確定」按鈕。這樣一來，CCE文件夾只有CCEUSER用戶才能訪問。

四 啟用磁碟配額

FTP伺服器磁碟空間資源是寶貴的，無限制的讓用戶使用，勢必造成巨大的浪費，因此要對每位FTP用戶使用的磁碟空間進行限制。下面筆者以CCEUSER用戶為例，將其限制為只能使用100M磁碟空間。

在資源管理器窗口中，右鍵點擊CCE文件夾所在的硬碟盤符，在彈出的菜單中選擇「屬性」，接著切換到「配額」標簽頁，選中伺服器託管「啟用配額管理」復選框，激活「配額」標簽頁中的所有配額設置選項，為了不讓某些FTP用戶佔用過多的伺服器磁碟空間，一定要選中「拒絕將磁碟空間給超過配額限制的用戶」復選框。

然後在「為該卷上的新用戶選擇默認配額限制」框中選擇「將磁碟空間限制為」單選項，接著在後面的欄中輸入100，磁碟容量單位選擇為「MB」，然後進行警告等級設置，在「將警告等級設置為」欄中輸入「96」，容量單位也選擇為「MB」，這樣就完成了默認配額設置。伺服器託管此外，還要選中「用戶超出配額限制時記錄事件」和「用戶超過警告等級時記錄事件」復選框，以便將配額告警事件記錄到Windows日誌中。

點擊配額標簽頁下方的「配額項」按鈕，打開磁碟配額項目對話框，接著點擊「配額→新建配額項」，彈出選擇用戶對話框，選中CCEUSER用戶後，點擊「確定」按鈕，接著在「添加新配額項」對話框中為CCEUSER用戶設置配額參數，伺服器託管選擇「將磁碟空間限制為」單選項，在後面的欄中輸入 「100」，接著在「將警告等級設置為」欄中輸入「96」，它們的磁碟容量單位為「MB」，最後點擊「確定」按鈕，完成磁碟配額設置，這樣CCEUSER 用戶就只能使用100MB磁碟空間，超過96MB就會發出警告。

五 TCP/IP訪問限制

為了保證FTP伺服器的安全，還可以拒絕某些IP地址的訪問。在默認FTP站點屬性對話框中，切換到「目錄安全性」標簽頁，選中「授權訪問」單選項，然後在「以下所列除外」框中點擊「添加」按鈕，彈出「拒絕以下訪問」對話框，這里可以拒絕單個IP地址或一組IP地址訪問，伺服器託管以單個IP地址為例，選中「單機」選項，然後在「IP地址」欄中輸入該機器的IP地址，最後點擊「確定」按鈕。這樣添加到列表中的IP地址都不能訪問FTP伺服器了。

六 合理設置組策略

通過對組策略項目的修改，也可以增強FTP伺服器的安全性。在Windows2000系統中，進入到「控制面板→管理工具」，運行本地安全策略工具。

1. 審核賬戶登錄事件

在本地安全設置窗口中，伺服器託管依次展開「安全設置→本地策略→審核策略」，然後在右側的框體中找到「審核賬戶登錄事件」項目，雙擊打開該項目，在設置對話框中選中「成功」和「失敗」這兩項，最後點擊「確定」按鈕。該策略生效後，FTP用戶的每次登錄都會被記錄到日誌中。

2. 增強賬號密碼的復雜性

一些FTP賬號的密碼設置的過於簡單，就有可能被「不法之徒」所破解。為了提高FTP伺服器的安全性，必須強制用戶設置復雜的賬號密碼。

在本地安全設置窗口中，伺服器託管依次展開「安全設置→賬戶策略→密碼策略」，在右側框體中找到「密碼必須符合復雜性要求」項，雙擊打開後，選中「已啟用」單選項，最後點擊「確定」按鈕。

然後，打開「密碼長度最小值」項，為FTP賬號密碼設置最短字元限制。這樣以來，密碼的安全性就大大增強了。

3. 賬號登錄限制

有些非法用戶使用黑客工具，反復登錄FTP伺服器，來猜測賬號密碼。這是非常危險的，因此建議大家對賬號登錄次數進行限制。

依次展開「安全設置→賬戶策略→賬戶鎖定策略」，伺服器託管在右側框體中找到「賬戶鎖定閾值」項，雙擊打開後，設置賬號登錄的最大次數，如果超過此數值，賬號會被自動鎖定。接著打開「賬戶鎖定時間」項，設置FTP賬號被鎖定的時間，賬號一旦被鎖定，超過這個時間值，才能重新使用。

通過伺服器託管以上幾步設置後，用戶的FTP伺服器就會更加安全，再也不用怕被非法入侵了。

㈩ Web伺服器性能和站點訪問性能該如何優化

今天小編要跟大家分享的文章是關於Web伺服器性能和站點訪問性能該如何優化?正在從web前端工作的小夥伴們來和小編一起看一看吧！

一、優化思路淺析


要優化Web伺服器的性能，我們先來看看Web伺服器在web頁面處理上的步驟：


1、Web瀏覽器向一個特定的伺服器發出Web頁面請求;


2、Web伺服器接收到web頁面請求後，尋找所請求的web頁面，並將所請求的Web頁面傳送給Web瀏覽器;


3、Web瀏覽器接收到所請求的web頁面內容，並將它顯示出來。


上面三個步驟都關系Web伺服器，但實際Web伺服器性能相關最大的是在第2步，這里Web伺服器需要尋找來自瀏覽器所請求的Web
頁面內容。


我們知道，Web頁面內容有靜態的，也有動態的，靜態的內容，web
伺服器可以直接將結果發回給瀏覽器，對於動態內容，則通常需要交給應用伺服器先處理，由應用伺服器返回結果。


當然，也有Web伺服器本身可以處理動態內容的，例如IIS就可以自已解釋處理ASP,ASP.NET這兩種微軟的動態網頁腳本語言。


從上面簡要的分析里，我們大致可以得到這樣的結論，影響Web頁面訪問的影響因素會有這幾個：


1、Web伺服器從磁碟中讀取靜態頁面內容的速度，也即時間;


2、Web伺服器判定請求內容是靜態還是動態內容的時間;


3、Web伺服器轉發請求給應用伺服器的時間;


4、應用伺服器處理(解釋)動態內容所需的時間;


5、Web伺服器返回Web內容給瀏覽器的響應時間;


6、Web伺服器接收來自瀏覽器請求的處理性能;


7、Web訪問請求數據在網路上傳輸的時間：包括從瀏覽器到伺服器，和從伺服器到瀏覽器兩部分;


8、瀏覽器本地計算和渲染Web內容的時間，即接收內容後展現內容的時間。


上面8項很容易理解，也很直接，其實還有以下幾項也是關乎Web
頁面訪問速度體驗的因素，你可以思考下是否如此?或者說是否會影響到頁面訪問性能。


§Web伺服器執行安全策略檢查的時間，或者說性能;


§Web伺服器讀取日誌文件、寫日誌內容、關閉對日誌文件訪問的時間，先讀後寫再關閉，這三步中的讀與寫又涉及到磁碟訪問性能因素;


§同時與Web伺服器連接會話的客戶端數量大小，即並發訪問量多大。


我們可以將上面的影響因素抽像出來，那麼就是：


1、Web伺服器磁碟性能;


2、Web伺服器與應用伺服器交互的性能;


3、應用伺服器處理動態內容的性能，或者說動態內容應用處理性能;


4、客戶端與Web伺服器的連接速度，即網路傳輸性能;


5、Web瀏覽器解釋和渲染Web內容的性能;


6、Web訪問並發性能。


反映到我們進行性能優化，可以入手的角度就有：


1、增加帶寬，包括伺服器和客戶端兩邊的Internet連接帶寬;


2、加快動態內容的處理性能;


3、盡可能多地使用靜態內容，這樣Web伺服器就可以無需請求應用伺服器，直接將Web內容發給瀏覽器端，這里可以入手的方案又有：


動態內容緩存


動態內容靜態化


多台伺服器負載均衡同時處理大量的並發訪問;


提升伺服器磁碟訪問性能，也即通常所說的I/O性能;


減少網頁中的HTTP請求數;


更換更好性能的Web伺服器;


合理部署伺服器，在離客戶端更近的地方部署伺服器，已經證明可以明顯地提升訪問性能。


二、性能優化實踐


經過前面小節的簡要分析，相信你對優化Web伺服器有一定的思路了，你可以從硬體層面、軟體層面、Web代碼三個層面去優化。


下面我們結合一個具體的實例來實踐一回，本文所舉例是一個小型的Web
站點，部分數據系假設，如有類同，純屬巧合，僅起拋磚引玉之用。在實際工作中，如果碰到大站點，你可以參考此處的分析，修改優化方案。


1.站點簡介


一個社區論壇站點，採用Discuz!論壇程序構建，該程序採用主流的PHP+MySQL組成。


網站目前有近5萬注冊用戶，絕大多數是國內的用戶，活躍用戶數在一半左右，每天平均PV在15~20萬，獨立訪問IP數在8000
左右。


2.Web伺服器性能優化需求


網站現部署在國外的伺服器，租用虛擬主機來運營，因為訪問量比較大，所以經常會收到虛擬主機服務商的流量很大的通知，要求控制下訪問量。


另外，虛擬主機的伺服器在美國，沒有在國內租用虛擬主機的原因是國內網站在備案方面非常繁瑣，在網站一開始運營時數據量和訪問量都比較小，所以對性能要求不高，數據量小，所以伺服器在查詢處理數據時速度比較快，也讓人感覺訪問速度不慢，現在隨著數據量和訪問量的不斷上升，訪問速度已明顯下降，到了需要改善訪問性能的時候了。


基於目前該社區網站的情況，提出的優化需求是，國內訪問速度需要提升一倍，目前首頁載入時間需要40秒左右，希望優化後能在20
秒以內將首頁載入完成。


另外提出網站數據能夠每天自動備份一次，備份數據保留一個月的，以便隨時恢復。


上述兩點需求，其中第一條才是性能優化需求，第二條是額外的需求了。


3.性能優化方案


根據其網站的現狀和優化需求，結合自己的經驗，加上谷歌的搜索，同時與網站主不斷確認溝通，最終得到以下性能優化方案：


由虛擬主機部署改為獨立伺服器部署


虛擬主機受限比較多，無法自己自定義配置Web伺服器，無法配置PHP
動態緩存，而且獨立伺服器可以獨享內存、處理器資源，不再受虛擬主機商對每個虛擬主機用戶的內存和處理器資源佔用限制。處理器資源和內存資源，對接受更多並發訪問有直接性能提升效果。


獨立伺服器，我們選用Linode2048型號，2G內存，4核處理器(Linode所有VPS都是四核處理器)，80G硬碟空間，800G
網路流量。


由Windows操作系統改為Linux操作系統


網站使用的是PHP+MySQL程序，PHP在Windows下的性能，受限於IIS需要通過ISAPI形式調用PHP，所以性能不如
Linux下Apache直接通過PHP模塊解釋PHP，更不如Nginx與PHP-FPM
的性能，既然使用了獨立伺服器，操作系統也可以自己確定，Linux系統我們選用了熟悉的UbuntuLinuxServer10.04(一年前還沒有
12.04)，^-^。


Web伺服器採用Nginx，而不使用Apache


選用Nginx而不用Apache的原因非常直接和乾脆，因為站點里有很多靜態的附件文件，在處理靜態內容上，Nginx性能是Apache
的差不多10倍。


在PHP解釋和偽靜態規則方面，Apache要比Nginx強，但這不影響我們放棄它，為緩解這一點，我們在後面對PHP
進行了動態緩存。


對PHP查詢進行動態緩存，使用eAccelerator這個加速器


PHP加速器是一個為了提高PHP執行效率，從而緩存起PHP的操作碼，這樣PHP後面執行就不用解析轉換了，可以直接調用PHP
操作碼，這樣速度上就提高了不少。


eAccelerator是一個開源PHP加速器，優化和動態內容緩存，提高了PHP腳本的緩存性能，使得PHP
腳本在編譯的狀態下，對伺服器的開銷幾乎完全消除。它還有對腳本起優化作用，以加快其執行效率。使得的PHP程序代碼執效率能提高1-10
倍，這個加速還是非常明顯的。


具體地，我們計劃對eAccelerator進行以下設置優化：


§緩存使用物理內存來進行，不使用磁碟來緩存。我們知道內存的讀寫性能是硬碟的N倍，所以在內存資源可以安排情況下，強烈建議使用內存來保存
eAccelerator的緩存內容。


§緩存大小設置為32MB，這個值是操作系統默認支持最大的緩存容量。雖然可以通過修改配置文件來加大這個值，但我們覺得沒有必要，所以就放棄了。


Nginx性能優化


選用了Nginx，雖然它的性能很好，但我們仍然需要對它進行性能優化，在這個案例中，我們做了以下優化：


§使用8個進程，每個進程大約需要20M內存消耗，這里一共使用了150M左右的內存。


§充分使用主伺服器的CPU內核：四核，使用CPU粘性配置選項(worker_cpu_affinity)，每核處理器分配兩個進程。


§開啟gzip壓縮功能：gzip壓縮對JS,CSS,XML壓縮效果非常好，能壓縮一半，即減少一倍的傳輸時間;對圖片文件，JPG
已經壓縮過的，它的壓縮性能要少一些。


§圖片本地緩存1天：網站上的圖片很多，通常一張圖片上傳後，不會頻繁的修改，只會頻繁的訪問，所以將圖片放在Nginx
緩存里，可以減少伺服器訪問載入次數，提升訪問速度。


§JS、CSS文件本地緩存7
天：這兩種網頁文件，平時都不會去修改它，將它緩存起來，可以減少載入次數，提升訪問速度。為什麼這兩種文件不和圖片一起設置緩存有效期，是考慮了不同文件的修改頻率不一樣。


§Nginx日誌每天切割一次：這個優化項能大大減小Nginx日誌文件的大小，經過一周的查看，每天的日誌文件是50M
左右，如果不是每天切割，用月切割，那一個月的日誌文件就是幾個G，要Web
伺服器在內存里載入這么大的文件，系統本身內存不夠用，就自然會用到磁碟來緩存，這就影響性能。每天50M左右，在內存上完全可以順利載入，這樣Nginx
在處理訪問時，可以快速的保存訪問日誌。


經過上述幾個優化項目，Nginx這邊一共需要佔用200M左右內存資源。


對PHPCGI進程性能進行優化


Nginx沒有PHP模塊，所以它對PHP的支持是通過PHP-FPM來實現的，PHP-FPM
是跑進程來處理並發請求，在這個案例中，我們配置了20個進程，每個進程差不多佔用20M左右內存資源，一共是400M左右。


同時，PHP-FPM與Nginx交互機制，選用LinuxSocket模式而不是TCP協議埠，Socks是系統級處理模式，socks
也就是一個文件連接，而TCP協議埠，需要經過網路協議處理，性能不如前者，所以我們選擇了前者。


MySQL資料庫性能優化


因為網站主程序是選用他人開發的開源程序，所以對資料庫查詢的程序優化我們無法處理，只能從MySQL本身尋找突破口。


我們可以想像一下，對於論壇網站，通常看貼、查貼的訪問量要遠大於創建貼子、回復貼子的訪問量，體現在MySQL
資料庫上，就是讀表與查詢表數據的連接處理更多。


因此我們要選擇對讀表、查詢性能更好的存儲引擎，結合以前了解的知識，MySQL預設的MyISAM
引擎就是被設計為適合處理讀頻率遠大於寫頻率的環境，查詢效率相當可觀，而且內存佔用很少，這也與我們租用低內存配置的VPS相符。


具體到MySQL配置參數的優化上，受限於伺服器上內存資源本身有限，就直接採用預設的中型環境配置文件。


內容分發網路應用


站點每天十多萬的訪問，上萬獨立IP
訪問，查看先前的訪問統計，訪問來自國內各個地區，使用多種網路連接訪問進來，為保證來自各網路的用戶訪問速度，同時也減少對網站伺服器的請求，我們採用了CDN
來分發靜態內容，這樣各地的用戶可以就近訪問到已緩存在CDN上的文件，CDN
服務商會在靜態內容第一次訪問時緩存到他們全國各地的伺服器上，當第二次訪問時，用戶實際是沒有連接到網站伺服器上獲取文件的，而是直接從CDN
伺服器上獲取，可以明顯的提升網站性能。


以上就是小編今天為大家分享的關於Web伺服器性能和站點訪問性能該如何優化的文章，希望本篇文章能夠對正在從事web前端工作的小夥伴們有所幫助。想要了解更多web前端相關知識記得關注北大青鳥web培訓官網。最後祝願小夥伴們工作順利！