伺服器並發處理能力概述

3.1 吞吐率(Throughput)

：單位時間內伺服器處理的請求數來描述其並發的處理能力。

3.1.1 吞吐率和壓力測試

：通過類比足夠數目的並發使用者數，分別持續發送一定的HTTP請求，並統計測試持續的總時間，計算出基於這種壓力下的吞吐率，即為一個平均值。

3.1.2 壓力測試的前提條件

：一些潛在的前提，那就是壓力的描述和請求性質的描述：

. 並發使用者數

：指在某一時刻同時向伺服器發送請求的使用者總數(HttpWatch)

. 總請求數

. 請求資源描述

. 請求等待時間(使用者等待時間)

. 使用者平均請求的等待時間。

. 伺服器平均請求處理的時間。

. 硬體環境

3.2 CPU並發計算

：伺服器之所以可以同時處理多個請求，在於作業系統通過多執行流體系設計使得多個任務可以輪流使用系統資源，這些資源套件括CPU、記憶體以及I/O等。

3.2.1 進程

：多執行流一般實現是進程，多進程的好處並不僅僅在於CPU時間的輪流使用，還在於對CPU計算和I/O操作進行了很好的重疊利用，這裡的I/O主要是指磁碟I/O和網路I/O，進程大多時間都消耗在I/O操作上，現代電腦的DMA技術可以讓CPU不參與I/O操作的全進程。

3.2.2 輕量級進程

：它是由一個新的系統調用clone()來建立，並由核心直接管理，像普通的進程一樣獨立存在，各自擁有進程描述符，但是這些進程已經允許共用一些資源，比如地址空間，開啟的檔案等。輕量級進程減少了記憶體的開銷，並為多進程應用程式的資料共用提供了直接支援，但是其環境切換的開銷還是在所難免的。

3.2.3 線程

：Posix 1003.1c 為linux定義了線程的介面"pthread"，有些不是由核心來直接支援，多線程只是一個普通的進程，它是由使用者態通過一些庫函數類比實現的多執行流，所以多線程的管理完全在使用者態完成，這種實現方式下線程切換的開銷相比於進程和輕量級進程都要少些，但是它在多處理器的伺服器(SMP)中表現較差，因為只有核心的進程調試器才有權利分配多個CPU時間。

：LinuxThreads，它可以說是核心級線(Kernel-Lerel-Threads)，因為它通過clone()來建立進程，它的實現原理是將線程和輕量級進程進行一對一關聯，每個線程實際上就是一個輕量級進程，這樣使得線程完全由核心的進程調試器來管理，所以它對於SMP的支援較好，但是線程切換的開銷相比於使用者態線程要多一些。

3.2.4 進程高度器

：單CPU同時刻只有一個進程處於運行狀態，而其它進程有的處於掛起狀態並等待就緒，有的已經就緒並等待CPU時間片，還有的處於其它狀態。核心中的進程高度器(Scheduler)維護著各種狀態的進程隊列，在Linux中，進程調度器維護著一個包括所有可運行進程的隊列，稱為“運行隊列”(Run Quere)，以及一個包括所有休眠進程和殭屍進程的列表。進程調試器的一項重要工作就是決定下一個啟動並執行進程，如果運行隊列中有不止一進程就按照優先順序。調試器也動態調整它們的最佳化級。具體可聽聽(視頻: 嵌入式Linux效能監控和調優--華清遠見嵌入式培訓視http://v.youku.com/v_show/id_XMTAyODIzNTM2.html)

3.2.5  系統負載

：在進程調試器維護的運行隊列中，任何時刻至少存在一個進程，那就是正在啟動並執行進程，正當運行隊列中有不止一個進程的時候，就說明此時的CPU比較搶手，其它進程還在等著，進程調試器應該儘快讓正在啟動並執行進程釋放CPU。通過 cat /proc/loadavg

[root@web102 ~]# cat /proc/loadavg
0.00 0.00 0.00 1/102 23534

0.00 0.00 0.00   最近1分鐘、5分鐘、15分鐘分別計算得出的系統負載

1/102            運行隊列中的進程個數/此時的進程總數

23534            代表到此為止，最後建立的一個進程ID

簡單密集型CPU計算程式：

<?php $max = 10000000000; $sum = 0; for ($i = 0; $i < $max; ++$i)  {    $sum += $i;  } echo $sum;?>