1、如何提高伺服器並發數
消除瓶頸是提高伺服器性能和並發能力的唯一途徑。
如果你能夠消除所有的瓶頸,你就能夠最大的發揮硬體性能,讓系統的性能和並發數到達最佳。
採用多線程多核編程,使用事件驅動或非同步消息機制,盡量減少阻塞和等待操作(如I/O阻塞、同步等待或計時/超時等)。
原理:
1、多線程多核編程,消除cpu瓶頸。
2、採用IOCP或epoll,利用狀態監測和通知方式,消除網路I/O阻塞瓶頸。
3、採用事件驅動或非同步消息機制,可以消除不必要的等待操作。
4、如果是Linux,可以採用AIO來消除磁碟I/O阻塞瓶頸。
5、在事件驅動框架或非同步消息中統一處理timer事件,變同步為非同步,而且可以在一個線程處理無數timer事件。
6、深入分析外部的阻塞來源,消除它。
比如資料庫查詢較慢,導致伺服器處理較慢,並發數上不去,這時就要優化資料庫性能。
7、如果與某個其他server通信量很大,導致性能下降較多。
可以考慮把這兩個server放在一個主機上,採用共享內存的方式來做IPC通信,可以大大提高性能。
2、1000個用戶並發的網站伺服器大概需要什麼樣的配置?
並發數
不能作為配置參考
關鍵是你網站
和數據的性質啊
說個例子你就明白了
如果是視頻站
並發1000
那可實實在在同時的高流量並發
必須高帶寬
高配置應對
可如果是文字小說站呢
那就算並發也沒那麼大影響
你也知道你普通的並發
和那8000的區別了
所以關鍵不是數字
而是性質
決定配置
3、如何測試伺服器支持的最大並發連接數
更改服務端的I/O模型吧,這明顯是服務端設計的問題。
你這樣設計上線使用的話,伺服器開銷太大了(主要是線程切換的開銷)。
//--------------------
Listen(socket,5),跟這個有一定關系。
int listen(int sockfd, int backlog); 第二個參數是你監聽客戶端的最大個數,如連接到主機上的客戶端超過其數listen則會返回一個錯誤代號。
backlog你可以設置大一點,如100之類的。
建議使用I/O模型吧,不要使用建立新線程來處理。
(你使用建立新線程的話,會發現每個進程所建立的最大線程數量是有一個限制的)
4、如何測試網站最大並發數
不同的伺服器有默認的最大並發數,當然默認是默認,實際承不承受得住就需要通過測試來試了,
測試網站壓力有很多軟體,,,
JMeter,比較好用,教程網上可以找到,,有中文版。。。
5、什麼是伺服器並發量?並發量如何計算
並發的意思是指網站在同一時間訪問的人數,人數越大,瞬間帶寬要求更高。伺服器並發量分為: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
6、多線程處理時,並發量過大時該如何避免伺服器崩潰
盡量使用緩存,包括用戶緩存,信息緩存等,多花點內存來做緩存,可以大量減少與資料庫的交互,提高性能。
1、用jprofiler等工具找出性能瓶頸,減少額外的開銷。優化資料庫查詢語句,減少直接使用hibernate等工具的直接生成語句(僅耗時較長的查詢做優化)。優化資料庫結構,多做索引,提高查詢效率。
2、統計的功能盡量做緩存,或按每天一統計或定時統計相關報表,避免需要時進行統計的功能。
3、能使用靜態頁面的地方盡量使用,減少容器的解析(盡量將動態內容生成靜態html來顯示)。
4、解決以上問題後,使用伺服器集群來解決單台的瓶頸問題。基本上以上述問題解決後,達到系統最優。
7、游戲服務端大訪問量大並發的優化解決方案?
所有的對象都放在內存,20萬用戶以下無壓力。
如果游戲的用戶很多,例如超過50萬,內存就會不夠,可使用LRU演算法來淘汰一些數據。
流程:收到用戶請求 - 在內存查找用戶對象 - 如果不存在就從資料庫中載入- 放入內存cache-如果cache中的用戶超過20萬 - 用LRU演算法淘汰最古老的用戶數據。
避免同步的IO操作,所有會發生寫資料庫的操作:例如角色獲得了經驗,要更新資料庫;這類和游戲邏輯相關、安全性要求不高的保存操作,一律用非同步操作,由後台的資料庫保存線程定期保存。
流程:如果要保存到資料庫 - 檢查該對象是否已有標志為在保存隊列中 - 如果為假 - 將對象放入保存隊列。 後台保存線程的流程:從隊列中獲取要保存的對象 - 保存 - 置保存標志位為假。
內存cache + 非同步保存模式,並發 每秒1000+ 不會有任何壓力,而且正常情況下每個請求的處理時間不會超過50毫秒。
郵件操作一定產生大量IO操作,而且都是同步操作,可用上面的cache機制處理,或者專門的郵件伺服器。
如果是DNF之類的格鬥類游戲,因為對系統響應的時間要求特別高,50毫秒都嫌慢,這種情況下,瓶頸是在網路上,可用UDP包來解決。搜索UDP,有大量文檔。
如果用戶數是海量的,例如超過500萬,或者對並發的要求更高,例如每秒5000+次請求,這種指標明顯超過了單機的處理能力,這個時候就必須採用分布式結構,使用多台伺服器。可參照EJB二次遠程調用的原理實現多機分布式結構,搜索EJB,也有大量文檔。
沒事不要用c或者c++寫游戲伺服器端,c#和java這類歷史悠久、有大量工具包、程序員一抓一大把的語言最好。性能不是問題,少BUG、穩定、開發周期短才是最重要的。
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、並發數與伺服器配置的關系,能舉個例子說明一下嗎?
做網站的話,伺服器要分前端和後端的,還有cache、負載平衡、網路帶寬和存儲系統等問題要考慮,不是單講一台伺服器就能說清楚的。
只討論一台伺服器的話,3650雙路加4G內存支持到5萬並發是容易達到的,即使針對業務流比較復雜的情況,也能滿足很大程度的需要。
但是考慮到存儲子系統,比如4塊sas硬碟raid0,可能只能達到5000數量級的並發請求。如果是以另外的光纖盤陣來支持存儲則可以顯著提高硬碟傳輸帶寬的性能。
最後還要考慮到你的網路帶寬,對大多數網站來說,通常這才是最大的瓶頸所在。也就是說即使你的cpu、內存、硬碟都沒問題,也會因為租用的網路帶寬限制而影響最大的並發數。
還有一點,經過優化的網站程序對結果也有很大影響。事實上很多網站的訪問體驗很糟糕,其實不是因為硬體的原因,而是程序寫的太爛。
很抱歉我本想以單台伺服器來講,但是說著說著又變成講網站架構了。不如舉個例子吧,如果你在這台伺服器上運行discuz或動網之類的服務,在沒有特別高峰的情況下,5萬並發是沒有問題的。
10、2個4核的CPU +4G的內存,這樣的伺服器最大能支持多少用戶並發
這個配置的伺服器,如果是國內大商家的話,每天跑幾萬pv訪問量是沒問題的。
小商家就不一定了。畢竟硬體伺服器的質量是不同的,穩定性、速度、網路都會有很大差別。
你問這個問題的時候,要綜合考慮自己業務的實際情況來判斷夠不夠用。