oracle的最大併發數由processes和sessions決定，歸根結底由作業系統和硬體配置決定。
tomcat的單機併發最大執行緒數為500到700。
druid資料庫連線池的推薦配置最大併發數（maxactive）為20.
oralce的最大程序數（processes）為300，最大sessions為300 * 1.5 + 22 = 477 （這個公式對應oracle 11g版本）
nginx在windows上的最大併發數為1024，在linux為8192.（受限於檔案系統的最大檔案開啟數）。
基於以上資料，進行推測：
資料庫最大併發 = 300
資料庫可以支援的連線池個數 = 477 / 20 = 23
23個連線池對應23個tomcat，可以支撐的執行緒數：
23 * 500 = 11500個執行緒
所以11500個併發並不代變11500個使用者，具體要看實際場景中乙個使用者的單位時間訪問量。
下面來驗證以上推測。
環境準備：
測試客戶端：
tomcat執行緒池配置
5個伺服器上分散部署了共13個tomcat和1個nginx
首先，按照7500執行緒在70秒內全部發起請求，得到的結果是：前面十秒左右一切正常，10秒過後nginx開始大量請求無法響應（failed to response），原因是nginx所在的windows伺服器限制了最大檔案開啟數量為1024，也就是限制了nginx的併發數為1024.
馬上把nginx轉移到linux上，其他不變。
此時，按照7500執行緒70秒內發起的結果如下：
執行緒數時間
發出請求
平均響應
95%響應
錯誤率吞吐量
資料庫平均cpu%
資料庫峰值cpu%
3750*2
54s7499
12721ms
60147ms
15.12%
40.8/s
60%100%
3750*2
54s7498
13753ms
60358ms
13.27%
61.8/s
66%100%
5750*2
83s11490
15669ms
60384ms
15.97%
56.4/s
76%100%
5750*2
83s11489
19229ms
60376ms
31.3%
78.4/s
50%100%
5750*2
83s11489
19037ms
60313ms
36.3%
67.56/s
60%100%
說明：執行緒數乘2的原因是測試指令碼包含兩個請求，分別是登入請求和載入閱卷頁面的請求。
根據壓測過程中的監控，錯誤率裡面85%來自登入請求的連線超時錯誤。正常情況下，這個系統的登入請求耗時1到1.5秒左右，併發場景下更嚴重。
由於這次部署的tomcat例項數是13個，每個tomcat的最大執行緒數是500，最大同時active的執行緒數就是7500，離預估的資料庫最大承受值11500還差一點。湊齊20多個tomcat的工作量太大，就不繼續壓榨oracle了。基於已有的測試結果，基本可以驗證上面的推測。
oracle最大併發數檢視
分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！檢視oracle的最大併發數限制，可是檢視v license檢視 v license檢視 裡面記錄了oracle最大的併發數以及當前使用者的連線數，官方文件有如下描述 this view contains information about lic...
基於PowerMokito的單測
1.接入pom org.mockito mockito core 1.10.19 test org.powermock powermock module junit4 1.6.4 test org.powermock powermock api mockito 1.6.4 test org.spri...
從最佳併發使用者數和最大併發使用者數看效能測試
文章中介紹乙個理髮店理論，然後引出最佳併發使用者數和最大併發使用者數的概念 背景 理髮店共有3名理髮師，每名理髮師完成一次理髮都耗時1小時，店裡有還有一些位子供客人等位，每個客人在理髮店呆的時間超過3小時就會無法忍受離開。我理解的幾個概念 3名理髮師，好比應用同時能處理幾個事務 理髮耗時1小時，好比...