導航:首頁 > IDC知識 > 伺服器並發執行

伺服器並發執行

發布時間:2021-02-23 14:43:23

1、網站伺服器的並發是什麼意思

就是伺服器支持多少個用戶同時訪問。1個訪問就是1個並發數,這些並發數的計算,包括使用計算機的所有方式,比如說遠程桌面,web用戶訪問等等。

2、高並發的伺服器有什麼模式

服務程序最為關鍵的設計是並發服務模型,當前有以下幾種典型的模型:

  - 單進程服務,使用非阻塞IO

使用一個進程服務多個客戶,通常與客戶通信的套接字設置為非阻塞的,阻塞只發生在select()、poll()、epoll_wait()等系統調用上面。這是一種行之有效的單進程狀態機式服務方式,已被廣泛採用。

缺點是它無法利用SMP(對稱多處理器)的優勢,除非啟動多個進程。此外,它嘗試就緒的IO文件描述符後,立即從系統調用返回,這會導致大量的系統調用發生,尤其是在較慢的位元組傳輸時。

select()本身的實現也是有局限的:能打開的文件描述符最多不能超過FD_SETSIZE,很容易耗盡;每次從select()返回的描述符組中掃描就緒的描述符需要時間,如果就緒的描述符在末尾時更是如此(epoll特別徹底修復了這個問題)。

- 多進程服務,使用阻塞IO

也稱作 accept/fork 模型,每當有客戶連線時產生一個新的進程為之服務。這種方式有時是必要的,比如可以通過操作系統獲得良好的內存保護,可以以不同的用戶身份運行程序,可以讓服務運行在不同的目錄下面。但是它的缺點也很明顯:進程比較占資源,進程切換開銷太大,共享某些信息比較麻煩。Apache 1.3就使用了這種模型,MaxClients數很容易就可以達到。

- 多線程服務,使用阻塞IO

也稱之 accept/pthread_create模型,有新客戶來時創建一個服務線程而不是服務進程。這解決了多進程服務的一些問題,比如它佔用資源少,信息共享方便。但是麻煩在於線程仍有可能消耗光,線程切換也需要開銷。

- 混合服務方式
所謂的混合服務方式,以打破服務方和客戶方之間嚴格的1:1關系。基本做法是:

新客戶到來時創建新的工作線程,當該工作線程檢測到網路IO會有延遲時停止處理過程,返回給Server一個延遲處理狀態,同時告訴 Server被延遲的文件描述符,延遲超時時間。Server會在合適的時候返回工作線程繼續處理。注意這里的工作線程不是通過 pthread_create()創建的,而是被包裝在專門用於處理延遲工作的函數里。

這里還有一個問題,工作線程如何檢測網路IO會有延遲?方法有很多,比如設置較短的超時時間調用poll(),或者甚至使用非阻塞IO。如果是套接字,可以設置SO_RCVTIMEO和SO_SNDTIMEO選項,這樣更有效率。
除了延遲線程,Server還應提供了未完成線程的支持。
如有有特別耗費時間的操作,你可以在完成部分工作後停止處理,返回給Server一個未完成狀態。這樣Server會檢查工作隊列是否有別的線程,如果有則讓它們運行,否則讓該工作線程繼續處理,這可以防止某些線程挨餓。

典型的一個混合服務模型開源實現ServerKit

Serverkit的這些線程支持功能可簡化我們的服務程序設計,效率上應該也是有保證的。

2. 隊列(queue)

ServerKit提供的隊列是一個單向鏈表,隊列的存取是原子操作,如果只有一個執行單元建議不要用,因為原子操作的開銷較大。

3. 堆(heap)

malloc()分配內存有一定的局限,比如在多線程的環境里,需要序列化內存分配操作。ServerKit提供的堆管理函數,可快速分配內存,可有效減少分配內存的序列化操作,堆的大小可動態增長,堆有引用計數,這些特徵比較適合多線程環境。目前ServerKit堆的最大局限是分配單元必須是固定大小。

4. 日誌記錄

日誌被保存在隊列,有一個專門的線程處理隊列中的日誌記錄:它或者調用syslog()寫進系統日誌,或者通過UDP直接寫到遠程機器。後者更有效。

5. 讀寫鎖

GNU libc也在pthreads庫里實現了讀寫鎖,如果定義了__USE_UNIX98就可以使用。不過ServerKit還提供了讀寫鎖互相轉換的函數,這使得鎖的應用更為彈性。比如擁有讀鎖的若干個線程對同一個hash表進行檢索,其中一個線程檢索到了數據,此時需要修改它,一種辦法是獲取寫鎖,但這會導致釋放讀鎖和獲取寫鎖之間存在時間窗,另一種辦法是使用ServerKit提供的函數把讀鎖轉換成寫鎖,無疑這種方式更有效率。

除了以上這些功能,ServerKit還提供了資料庫連接池的管理(當前只支持MySQL)和序列化(Sequences),如感興趣可參見相關的API文檔。

二、ServerKit服務模塊編寫

ServerKit由3部分組成:server程序,負責載入服務模塊、解析配置文件、建立資料庫連接池;libserver,動態鏈接庫,提供所有功能的庫支持,包括server本身也是調用這個庫寫的;API,編程介面,你編寫的服務模塊和ServerKit框架進行對話的介面。

ServerKit需要libConfuse解析配置文件,所以出了安裝ServerKit,還需要安裝libConfuse。關於libConfuse可參考 http://www.nongnu.org/confuse/ 。

下面我們看一個簡單的服務模塊FOO:

#include <confuse.h>
#include <server.h>

static long int sleep_ration;

static int FOO_construct()
{
fprintf(stderr, "FOO_construct\n");

return 1;
}

static int FOO_prestart(cfg_t *configuration)
{
fprintf(stderr, "FOO_prestart\n");

return 1;
}

static void * FOO_operator(void *foobar)
{
fprintf(stderr, "FOO_operator\n");

for(;;) sleep(sleep_ration);

return NULL;
}

static void FOO_report(void)
{
fprintf(stderr, "FOO_report\n");
}


static cfg_opt_t FOO_config[] = {
CFG_SIMPLE_INT("sleep_ration", &sleep_ration),
CFG_END()
};

static char *FOO_authors[] = {"Vito Caputo <[email protected]>", NULL};


SERVER_MODULE(FOO,0,0,1,"Example mole that does nothing but sleep")按以下方法編譯:

$ gcc -c -fPIC -pthread -D_REENTRANT -g FOO.c
$ gcc -shared -lserver -lconfuse -lpthread -g -e __server_mole_main -o FOO.so FOO.o

-e選項指定程序運行入口,這使得你可以直接在命令行敲 ./FOO.so 運行模塊。
server程序根據環境變數SERVER_PERSONALITY_PATH定位主目錄,並查找主目錄下的c11n作為配置文件,動態載入的模塊需放在主目錄下的moles目錄。

$ export SERVER_PERSONALITY_PATH=`pwd`
$ mkdir moles
$ cp FOO.so moles
$ vi c11n

c11n的內容:

identity = "any_id"

FOO {
sleep_ration = 1;
}

identity標識server實例,用ps可看到程序名稱形如server.identity,本例為server.any_id。
執行server啟動服務程序。

三、ServerKit其他功能缺陷
缺乏daemon模式;
只能運行在Linux box;
DB pool只支持MySQL;
Heap管理內存的功力有限

3、關於java伺服器並發處理

我來告訴你吧,如果你用J2EE的話,現在所有的java的web容器,如weblogic、tomcat等其中都有一個servlet的java應用程序,回在web伺服器答啟動的時候就會載入它,這個應用程序就處理你的http數據請求了,而servlet本身就是實現了多線程,所以所有的請求處理你都可以看作是多線程的,不用你去管的,建議你看一下servlet的請求處理機制和生命周期。
另外一種就是你說的用socket了,首先你需要一個伺服器,在java中使用SocketServer來創建的,這樣會綁定一個埠來監聽客戶端發來的消息,按你說的每個消息都新創建一個線程來處理,如果有成千上萬的消息難道你每個都新啟一個線程來處理?顯然是不可能的,這里就要用到線程池了哈,簡單說就是把比如說100個線程放到一個池中,如果消息進來了首先去找這個池中的空閑線程,找到了就用這個線程處理,處理完了就讓這個線程空閑等待下一任務。如果沒有空閑線程就等待。所以這樣重復利用線程就可以完全達到你的目的了。

4、一台應用伺服器怎麼計算其並發量

並發的意思是指網站在同一時間訪問的人數,人數越大,瞬間帶寬要求更高。伺服器並發量分為:1.業務並發用戶數;2.最大並發訪問數;3.系統用戶數;4.同時在線用戶數;
說明伺服器實際壓力,能承受的最大並發訪問數,既取決於業務並發用戶數,還取決於用戶的業務場景,這些可以通過對伺服器日誌的分析得到。

一般只需要分析出典型業務(用戶常用,最關注的業務操作)

給出一個估算業務並發用戶數的公式(測試人員一般只關心業務並發用戶數)

C=nL/T

C^=C+3×(C的平方根)

C是平均的業務並發用戶數、n是login session的數量、L是login session的平均長度、T是指考察的時間段長度、C^是指業務並發用戶數的峰值。

假設OA系統有1000用戶,每天400個用戶發訪問,每個登錄到退出平均時間2小時,在1天時間內用戶只在8小時內使用該系統。

C=400×2/8=100

C^=100+3×(100的平方根)=100+3×10=130

另外,如果知道平均每個用戶發出的請求數u,則系統吞吐量可以估算為u×C

精確估算,還要考慮用戶業務操作存在一定的時間集中性(比如上班後1小時內是OA系統高峰期),採用公式計算仍然會存在偏差。

285-104-1346

5、socket java實現客戶端多線程接受消息並發送消息給伺服器,並發執行

對於通信來說,不存在絕對的伺服器和客戶端,誰在等待別人來,誰就是伺服器,誰主動去聯系人,誰就是客戶端。
所以。
你要想客戶端接受消息,那在啟動客戶端的時候,在客戶端程序里開始一個提供埠的Socket就可以了。
ServerSocket serverSocket = new ServerSocket(5000);
while (true) {
final Socket socket = serverSocket.accept();
new Thread() {
Socket mySocket = socket;

@Override
public void run() {
try {
System.out.println(mySocket);
InputStream is = mySocket.getInputStream();
byte[] bytes = new byte[1024];
int n = is.read(bytes);
System.out.println(new String(bytes, 0, n));
OutputStream os = mySocket.getOutputStream();
os.write(("server reply at time " + new Date()
.toString()).getBytes());
mySocket.close();
} catch (Exception e) {
e.printStackTrace();
}
}
}.start();
}

6、如何提高伺服器並發處理能力

有什麼方法衡量伺服器並發處理能力

1. 吞吐率

吞吐率,單位時間里伺服器處理的最大請求數,單位req/s

從伺服器角度,實際並發用戶數的可以理解為伺服器當前維護的代表不同用戶的文件描述符總數,也就是並發連接數。伺服器一般會限制同時服務的最多用戶數,比如apache的MaxClents參數。

這里再深入一下,對於伺服器來說,伺服器希望支持高吞吐率,對於用戶來說,用戶只希望等待最少的時間,顯然,雙方不能滿足,所以雙方利益的平衡點,就是我們希望的最大並發用戶數。

2. 壓力測試

有一個原理一定要先搞清楚,假如100個用戶同時向伺服器分別進行10個請求,與1個用戶向伺服器連續進行1000次請求,對伺服器的壓力是一樣嗎?實際上是不一樣的,因對每一個用戶,連續發送請求實際上是指發送一個請求並接收到響應數據後再發送下一個請求。這樣對於1個用戶向伺服器連續進行1000次請求, 任何時刻伺服器的網卡接收緩沖區中只有1個請求,而對於100個用戶同時向伺服器分別進行10個請求,伺服器的網卡接收緩沖區最多有100個等待處理的請求,顯然這時的伺服器壓力更大。

壓力測試前提考慮的條件

並發用戶數: 指在某一時刻同時向伺服器發送請求的用戶總數(HttpWatch)
總請求數
請求資源描述
請求等待時間(用戶等待時間)
用戶平均請求的等待時間
伺服器平均請求處理的時間
硬體環境
壓力測試中關心的時間又細分以下2種:

用戶平均請求等待時間(這里暫不把數據在網路的傳輸時間,還有用戶PC本地的計算時間計算入內)
伺服器平均請求處理時間
用戶平均請求等待時間主要用於衡量伺服器在一定並發用戶數下,單個用戶的服務質量;而伺服器平均請求處理時間就是吞吐率的倒數,一般來說,用戶平均請求等待時間 = 伺服器平均請求處理時間 * 並發用戶數

怎麼提高伺服器的並發處理能力

1. 提高CPU並發計算能力

伺服器之所以可以同時處理多個請求,在於操作系統通過多執行流體系設計使得多個任務可以輪流使用系統資源,這些資源包括CPU,內存以及I/O. 這里的I/O主要指磁碟I/O, 和網路I/O。

多進程 & 多線程

多執行流的一般實現便是進程,多進程的好處可以對CPU時間的輪流使用,對CPU計算和IO操作重疊利用。這里的IO主要是指磁碟IO和網路IO,相對CPU而言,它們慢的可憐。

而實際上,大多數進程的時間主要消耗在I/O操作上。現代計算機的DMA技術可以讓CPU不參與I/O操作的全過程,比如進程通過系統調用,使得CPU向網卡或者磁碟等I/O設備發出指令,然後進程被掛起,釋放出CPU資源,等待I/O設備完成工作後通過中斷來通知進程重新就緒。對於單任務而言,CPU大部分時間空閑,這時候多進程的作用尤為重要。

多進程不僅能夠提高CPU的並發度。其優越性還體現在獨立的內存地址空間和生命周期所帶來的穩定性和健壯性,其中一個進程崩潰不會影響到另一個進程。

但是進程也有如下缺點:

fork()系統調用開銷很大: prefork
進程間調度和上下文切換成本: 減少進程數量
龐大的內存重復:共享內存
IPC編程相對比較麻煩

7、tcp伺服器多個連接並發執行怎麼實現

線程是相對獨立的執行單位,是計算機系統進行調度的最小單位,其切換由回操作系統控制,稱之為答短作業調度。換句話說您沒有任何必要去手動調度線程。如果您想要實現的是連接分配的話,請參考您的操作系統的進程間通信和同步文檔,一般底層編程都是通過共享存儲區,消息隊列等方式實現的。如果是高層次的庫實現網路通信,請參考庫文檔,比如C#和Java都提供了足夠的介面實現此類功能。

8、如何提高伺服器並發能力

有什麼方法衡量伺服器並發處理能力

1. 吞吐率

吞吐率,單位時間里伺服器處理的最大請求數,單位req/s

從伺服器角度,實際並發用戶數的可以理解為伺服器當前維護的代表不同用戶的文件描述符總數,也就是並發連接數。伺服器一般會限制同時服務的最多用戶數,比如apache的MaxClents參數。

這里再深入一下,對於伺服器來說,伺服器希望支持高吞吐率,對於用戶來說,用戶只希望等待最少的時間,顯然,雙方不能滿足,所以雙方利益的平衡點,就是我們希望的最大並發用戶數。

2. 壓力測試

有一個原理一定要先搞清楚,假如100個用戶同時向伺服器分別進行10個請求,與1個用戶向伺服器連續進行1000次請求,對伺服器的壓力是一樣嗎?實際上是不一樣的,因對每一個用戶,連續發送請求實際上是指發送一個請求並接收到響應數據後再發送下一個請求。這樣對於1個用戶向伺服器連續進行1000次請求, 任何時刻伺服器的網卡接收緩沖區中只有1個請求,而對於100個用戶同時向伺服器分別進行10個請求,伺服器的網卡接收緩沖區最多有100個等待處理的請求,顯然這時的伺服器壓力更大。

壓力測試前提考慮的條件

並發用戶數: 指在某一時刻同時向伺服器發送請求的用戶總數(HttpWatch)
總請求數
請求資源描述
請求等待時間(用戶等待時間)
用戶平均請求的等待時間
伺服器平均請求處理的時間
硬體環境
壓力測試中關心的時間又細分以下2種:

用戶平均請求等待時間(這里暫不把數據在網路的傳輸時間,還有用戶PC本地的計算時間計算入內)
伺服器平均請求處理時間
用戶平均請求等待時間主要用於衡量伺服器在一定並發用戶數下,單個用戶的服務質量;而伺服器平均請求處理時間就是吞吐率的倒數,一般來說,用戶平均請求等待時間 = 伺服器平均請求處理時間 * 並發用戶數

怎麼提高伺服器的並發處理能力

1. 提高CPU並發計算能力

伺服器之所以可以同時處理多個請求,在於操作系統通過多執行流體系設計使得多個任務可以輪流使用系統資源,這些資源包括CPU,內存以及I/O. 這里的I/O主要指磁碟I/O, 和網路I/O。

多進程 & 多線程

多執行流的一般實現便是進程,多進程的好處可以對CPU時間的輪流使用,對CPU計算和IO操作重疊利用。這里的IO主要是指磁碟IO和網路IO,相對CPU而言,它們慢的可憐。

而實際上,大多數進程的時間主要消耗在I/O操作上。現代計算機的DMA技術可以讓CPU不參與I/O操作的全過程,比如進程通過系統調用,使得CPU向網卡或者磁碟等I/O設備發出指令,然後進程被掛起,釋放出CPU資源,等待I/O設備完成工作後通過中斷來通知進程重新就緒。對於單任務而言,CPU大部分時間空閑,這時候多進程的作用尤為重要。

多進程不僅能夠提高CPU的並發度。其優越性還體現在獨立的內存地址空間和生命周期所帶來的穩定性和健壯性,其中一個進程崩潰不會影響到另一個進程。

但是進程也有如下缺點:

fork()系統調用開銷很大: prefork
進程間調度和上下文切換成本: 減少進程數量
龐大的內存重復:共享內存
IPC編程相對比較麻煩

9、伺服器的並發是什麼意思,怎麼計算的!

伺服器並發指的是多個用戶同時訪問資料庫中的同一欄位的行為。這樣的用戶行為對於伺服器的性能是一種考驗。
但是,再好的伺服器也有自己的性能上限,當並發用戶數過多的時候,再好的伺服器也支持不住。事實上,我們在生活中經常能遇到由於並發用戶過多而導致的系統緩慢甚至癱瘓現象。比方說,很多使用過那些在線考試報名系統的朋友都會發現,半夜登錄系統報名比白天登錄系統報名要容,網頁反應速度也要快一些,這就是由於晚上的並發用戶數比較小的原因。
對於IT運維人員來說伺服器並發是恐怖的,因為伺服器的最大用戶並發數並不是IT運維人員所能控制的,我們能做到的只是採用各種手段來提升系統的性能,提升伺服器的性能利用率。

與伺服器並發執行相關的知識