下面這五條規則可以幫助你優化安裝的Drupal服務器，另外附有一些示例，說明如何運用這些規則。服務器優化是個龐大的領域，它在不斷進化，但是我們可以通過研究分析一些簡單的情況，了解比較復雜的情況。

下面我們側重于幾個變量，衡量它們對性能帶來的影響。

***條規則：要是不測試性能，優化就無從談起。

現在有好多工具可以用來準確地評估和測試性能，不過本文就著重介紹最重要的一款工具：Apache Benchmark。使用該工具在你的網站上查詢特定頁面（甚至可以向它傳送cooki信息，模擬通過驗證的用戶），以測量響應情況。你可以在接受測試的服務器上的命令行使用Apache Benchmark，同時仍能獲得有效的結果，因為該工具占用的處理器和內存資源很少。下面是一種典型的用法：

$ ab -n 1000 -c 20 http://example.com/
這里的值如下：
n = 頁面請求的數量
c = 并發連接的數量
最重要的參數是c，即并發請求的數量，而n這個數要足夠大，才能提供穩定的結果。關鍵在于，要使用不同的c值來測試網站，先從小的數值開始，逐步加大，直到“每秒請求”的返回值開始下降。比如說：
$ ab -n 1000 -c 20 http://example.com/ | grep ‘Requests per second’
每秒請求：45.29 [#/sec]（平均值）
$ ab -n 1000 -c 40 http://example.com/ | grep ‘Requests per second’
每秒請求：46.91 [#/sec]（平均值）
$ ab -n 1000 -c 60 http://example.com/ | grep ‘Requests per second’
每秒請求：8.55 [#/sec]（平均值）
$ ab -n 1000 -c 80 http://example.com/ | grep ‘Requests per second’
每秒請求：2.21 [#/sec]（平均值）

我們可以使用更小的增量來細化c值，但是以10為最接近倍數通常足矣。

#p# 第二條規則：減少占用的內存，直到分頁停止。

每秒請求數突然下降最有可能的原因是，我們讓內存過載，系統開始交換至分頁文件。這給總體性能帶來的影響與在Windows、Mac OS X或支持分頁機制的任何系統上打開過多應用程序帶來的影響一樣。

在你測試性能后，看一下使用了多少個交換文件。下面是4GB服務器上的典型值：

$ free -m
total used free shared buffers cached
Mem: 4011 1481 2530 0 45 824
-/+ buffers/cache: 611 3400
Swap: 8191 2145 8191

這里我們使用2145 MB大小的交換文件；在使用***的c值測試性能時，可能已創建了該文件。你首先要做的就是清空交換文件，然而查一下值是否回到零：

$ sudo swapoff -a
$ sudo swapon -a
$ free -m
total used free shared buffers cached
Mem: 4011 1379 2632 0 45 834
-/+ buffers/cache: 499 3512
Swap: 8191 0 8191

現在關鍵是，使用接近我們看到性能下降的那個值的c值，重新做一遍上面的測試，檢查每次請求后的分頁文件：

$ ab -n 1000 -c 30 http://example.com/ | grep ‘Requests per second’
每秒請求：45.93 [#/sec]（平均值）
$ free -m | grep Swap
Swap: 8191 0 8191
$ ab -n 1000 -c 40 http://example.com/ | grep ‘Requests per second’
每秒請求：40.31 [#/sec]（平均值）
$ free -m | grep Swap
Swap: 8191 312 8191
$ ab -n 1000 -c 50 http://example.com/ | grep ‘Requests per second’
每秒請求：12.27 [#/sec]（平均值）
$ free -m | grep Swap
Swap: 8191 1902 8191

你可以從上面的結果中看到，當服務器在約40個并發請求的情況下開始分頁時，請求速度大幅下降。

#p# 第三條規則：對連接而言，多就是少。

默認情況下，Apache和MySQL配置成接受150條連接。應用PHP的大多數系統（如Drupal）每個線程只會打開一條連接，所以你可以在連接兩頭，安全地將連接數量設成同一個值。說明一點，MySQL實際上允許n+1條連接，所以你有一條額外的連接用于管理。

遺憾的是，有些服務器管理員試圖“優化”服務器時，會將連接數量提高到500條、10000條或者甚至更多。要是服務器在負載狀態下運行，這會帶來嚴重影響。

Drupal網站通常每個請求需要超過32 MB的內存，你只要查看命令top返回的結果，就可以留意平均值：

$ top
top - 20:28:52 up 12:11, 2 users, load average: 1.34, 0.55, 0.35
Tasks: 93 total, 10 running, 83 sleeping, 0 stopped, 0 zombie
Cpu(s): 50.2%us, 21.4%sy, 0.0%ni, 28.0%id, 0.0%wa, 0.0%hi, 0.1%si, 0.3%st
Mem: 4108192k total, 1787064k used, 2321128k free, 46520k buffers
Swap: 8388604k total, 0k used, 8388604k free, 861772k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
32080 www-data 20 0 419m 64m 27m S 26 1.6 0:01.19 apache2
32110 www-data 20 0 419m 65m 28m S 25 1.6 0:01.69 apache2
32025 www-data 20 0 419m 63m 27m S 24 1.6 0:01.89 apache2
32065 www-data 20 0 417m 62m 27m S 22 1.6 0:01.13 apache2
32178 www-data 20 0 408m 53m 27m R 22 1.3 0:00.66 apache2
32024 www-data 20 0 418m 64m 28m R 21 1.6 0:02.85 apache2
32176 www-data 20 0 417m 62m 27m S 21 1.6 0:00.99 apache2
32032 www-data 20 0 408m 53m 27m S 21 1.3 0:02.45 apache2
32104 www-data 20 0 417m 62m 28m S 21 1.6 0:02.55 apache2
32116 www-data 20 0 415m 59m 27m R 21 1.5 0:01.79 apache2
32119 www-data 20 0 417m 62m 27m S 21 1.6 0:01.04 apache2
32164 www-data 20 0 417m 62m 27m R 21 1.6 0:00.99 apache2
32179 www-data 20 0 408m 53m 27m R 21 1.3 0:00.63 apache2
32222 www-data 20 0 403m 48m 27m S 17 1.2 0:00.50 apache2
23906 mysql 20 0 675m 115m 6628 S 14 2.9 2:33.85 mysqld
32147 www-data 20 0 419m 64m 27m R 14 1.6 0:02.26 apache2
32226 www-data 20 0 416m 56m 23m R 9 1.4 0:00.26 apache2

關鍵在于，估計Apache使用了多少內存，為此只要求進程所用的RES（常駐非交換物理內存）值的平均值。這里RES的平均值為約62MB。

你還要查看服務器在空載狀態下（這時沒有apache2進程在運行）的閑置內存量：
$ top
top - 20:40:45 up 12:23, 1 user, load average: 0.29, 0.38, 0.45
Tasks: 71 total, 1 running, 70 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.1%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 4108192k total, 1388132k used, 2720060k free, 46680k buffers
Swap: 8388604k total, 0k used, 8388604k free, 866208k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
32061 jfparadi 20 0 19272 1244 932 R 0 0.0 0:01.52 top
1 root 20 0 23628 1780 1244 S 0 0.0 0:00.64 init
2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0 0.0 0:02.56 ksoftirqd/0
4 root RT 0 0 0 0 S 0 0.0 0:00.02 migration/0
5 root RT 0 0 0 0 S 0 0.0 0:00.03 migration/1
6 root 20 0 0 0 0 S 0 0.0 0:01.19 ksoftirqd/1
7 root RT 0 0 0 0 S 0 0.0 0:00.03 migration/2
8 root 20 0 0 0 0 S 0 0.0 0:00.90 ksoftirqd/2
9 root RT 0 0 0 0 S 0 0.0 0:00.02 migration/3
10 root 20 0 0 0 0 S 0 0.0 0:00.74 ksoftirqd/3
11 root 20 0 0 0 0 S 0 0.0 0:01.94 events/0
12 root 20 0 0 0 0 S 0 0.0 0:01.91 events/1
13 root 20 0 0 0 0 S 0 0.0 0:01.79 events/2
14 root 20 0 0 0 0 S 0 0.0 0:03.11 events/3
15 root 20 0 0 0 0 S 0 0.0 0:00.00 cpuset
16 root 20 0 0 0 0 S 0 0.0 0:00.00 khelper
19 root 20 0 0 0 0 S 0 0.0 0:00.04 netns
20 root 20 0 0 0 0 S 0 0.0 0:00.00 async/mgr
23 root 20 0 0 0 0 S 0 0.0 0:00.00 xenwatch
24 root 20 0 0 0 0 S 0 0.0 0:00.00 xenbus
56 root 20 0 0 0 0 S 0 0.0 0:00.11 sync_supers

這里，閑置內存量是2720060KB，即2656MB。
現在，你需要使用這個簡單等式，確認上面發現的c值：
c = FREE / RES
c = 2656MB / 62MB
c = 43（接近上面發現的40）

這個值是服務器開始崩潰的閾值，我們要阻止Apache遇到這個極限值。我們可以將客戶端數量從150個減少到40個，看看對性能有什么影響。

如果是Apache，在你使用的特定MPM實現所對應的部分下面編輯配置文件，并調整這個值：
MaxClients 150
如果是MySQL，設置或調整這個值：
max_connections = 150
一旦你根據上面發現的數值（我們在這里使用40）調整了這些值，重新測試一下性能：
$ ab -n 1000 -c 20 http://example.com/ | grep ‘Requests per second’
每秒請求：44.43 [#/sec]（平均值）
$ free -m | grep Swap
Swap: 8191 0 8191
$ ab -n 1000 -c 40 http://example.com/ | grep ‘Requests per second’
每秒請求：45.11 [#/sec]（平均值）
$ free -m | grep Swap
Swap: 8191 0 8191
$ ab -n 1000 -c 60 http://example.com/ | grep ‘Requests per second’
每秒請求：43.27 [#/sec]（平均值）
$ free -m | grep Swap
Swap: 8191 0 8191
$ ab -n 1000 -c 80 http://example.com/ | grep ‘Requests per second’
每秒請求：44.59 [#/sec]（平均值）
$ free -m | grep Swap
Swap: 8191 0 8191

如你所見，分頁已被消除。但是為什么我們能夠響應超過40個的并發請求呢？完全是因為Apache將額外的請求放入隊列中，同時處理僅僅40個請求。客戶端響應仍會出現延遲，但是如果不讓內存過載，每秒響應的請求更多。此外，每秒請求數值保持穩定，因為處理速度取決于處理器。實際上，這兩個數都以等值單位：請求/秒和周期/秒來表示。

#p# 第四條規則：MySQL =內存

很顯然，上述結果假設數據庫已經過合理配置；假設我們沒有慢速查詢。實際上，對Drupal網站來說，MySQL通常并不耗用大量的處理器資源。在精心配置的服務器上，MySQL耗用的處理器資源只有10%到25%。

除了搜索活動外，查詢的冗余性很強；如果MySQL的緩存和線程能得到優化，MySQL就能從中得益。看到MySQL被配置成使用近50%的可用內存，這并不罕見。
很顯然，這個數依賴實際應用，原則就是為MySQL分配盡量多的內存。

#p# 第五條規則：Apache =處理器

在Drupal網站上，Apache的大多數時間用于執行PHP代碼。實際上，要看服務器有沒有得到優化，一個直觀的指標就是當Apache使用100%的可用處理器資源時；系統的其他所有瓶頸都消除后，通常才會出現這一幕。

那是由于，如果你允許Apache響應太多的并發請求，它就會將可用的處理器資源分配給每一個請求，因而每秒請求的速度就不會增加！

結論
我們在本文中僅僅探討了服務器優化的一些方面，而且作了幾個假設；不過我希望，上面這五條規則講得很清楚；希望它們會幫助你在部署時作出更明智的決定。
 
原文鏈接：http://www.appnovation.com/5-rules-optimize-your-server