伺服器並發

⑴ 網站服務器一般最多能同時接受多少個並發連接

Windows server 2003是沒有TCP/IP連接數限制的. 但一般默認安裝時,是有配置連接限制的,你可能事先配置的並發內連接數就是容100,你可以到"控制面板"中的"授權",去改一下,將每伺服器的同時連接數改成你要的數字,比如200或更大.如果你用的是盜版你高興改成1000也沒關系,如果用的是正版,那可要算算要花多少錢了,呵呵,多出來的許可證是要花錢買的! 好象真不行,要添加也有些問題,這個你知道了就好,下次裝03時,一定要配置一下,數字寫大點!如何改的問題,你查查看,有沒法改!

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

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

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

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

⑷ 1000個用戶並發的網站伺服器大概需要什麼樣的配置

一般的提法是1000並發，指同時在線數，即1000個客戶和伺服器保持著連接。可能一整內天容都能保持這個狀態，因此不帶上具體多久。

如果每秒1K個請求，每個請求都是寫入操作，數據大小是4K，那麼這是典型的資料庫應用。每秒需要寫入的數據量是1K*4K=4M。單機下普通配置的mongodb可以應付這樣的壓力。可否找一下那些地方成為瓶頸了。看看磁碟忙不忙，mongo的CPU高不高。

⑸ 什麼是伺服器並發量並發量如何計算

並發的意思是指網站在同一時間訪問的人數，人數越大，瞬間帶寬要求更高。伺服器並發量分為：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

⑹ 如何提高伺服器並發數

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

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

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

- 單進程服務，使用非阻塞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管理內存的功力有限

⑻ 超過伺服器的許可並發用戶數

25User是指終端授權並發連接用戶數，和你web服務的用戶數不是一碼事。

這個就是你有25個用戶可以使用server2003創建的服務，是支持25用戶連接到伺服器進行遠程登陸操作。可以裝25台機器是不正確的。

微軟對伺服器有兩種授權模式：「每伺服器」模式和「每客戶」模式。 用微軟官方的解釋即為：「每伺服器」模式要求同時連接伺服器的每個連接有單獨的「客戶訪問許可證（CAL）」。「每客戶」模式要求訪問的每台計算機都有單獨的CAL。
我們來打個比方：把公交車比做伺服器，把乘客比作客戶機，把乘客包車比作「每伺服器」模式中的CAL，把乘客的月票比作「每客戶」模式中的CAL。那麼，「每伺服器」模式就類似於一輛公交車被乘客包車了，乘客要坐進去就不需要任何憑證，但是車有其最大載客量，因此坐上去的乘客數不能超過其最大載客量。即如果一台伺服器有一個可連接數目為十的「每伺服器」模式的CAL，則它能同時連接任何十個客戶機，但如果要連入更多的客戶機，則需購買可連接數目更大的CAL。「每客戶」模式就好比一個乘客手中拿著一個月票，它就可以坐任何的公交車了。
系統在安裝過程中會讓你選擇一種授權模式，並讓填入連接數。建議選擇每伺服器模式，系統安裝好後還能修改為每用戶模式；如果選擇了每用戶模式，就無法修改了。

⑼ 影響web伺服器請求並發數量的因素

影響web伺服器請求並發數量的因素
只討論一台伺服器的話，3650雙路加4G內存支持到5萬並回發是容易達答到的，即使針對業務流比較復雜的情況，也能滿足很大程度的需要。
但是考慮到存儲子系統，比如4塊sas硬碟raid0，可能只能達到5000數量級的並發請求。如果是以另外的光纖盤陣來支持存儲則可以顯著提高硬碟傳輸帶寬的性能。
最後還要考慮到你的網路帶寬，對大多數網站來說，通常這才是最大的瓶頸所在。也就是說即使你的cpu、內存、硬碟都沒問題，也會因為租用的網路帶寬限制而影響最大的並發數。

⑽ 淺談如何提高伺服器並發能力

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

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

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