dubbo的服務提供者端一共包含了兩類執行緒池，一類叫做io執行緒池，還有一類叫做業務執行緒池，它們各自有著自己的分工，如下圖所示
all：將請求全部交給業務執行緒池處理（這裡面除了日常的消費者進行服務呼叫之外，還有關於服務的心跳校驗，連線事件，斷開服務，響應資料寫回等）
execution：會將請求處理進行分離，心跳檢測，連線等非業務核心模組交給io執行緒池處理，核心的業務呼叫介面則交由業務執行緒池處理。
假設說我們的dubbo介面只是一些簡單的邏輯處理，例如說下方這類:
@service
(inte***cename =
"msgservice"
)public
class
msgserviceimpl
implements
msgservice
}
dubbo.protocol.threadpool=fixed
dubbo.protocol.threads=
10dubbo.protocol.accepts=
5
dubbo.protocol.queues=
100
測試環境：
mac筆記本，jvm：-xmx 256m -xms 256m但是假設說我們的dubbo服務內部做了一定的業務處理，耗時較久，例如下方：
@service
(inte***cename =
"msgservice"
)public
class
msgserviceimpl
implements
msgservice
}
此時大部分的請求都會因為業務執行緒池中的數目有限出現堵塞，因此導致大量的rpc呼叫出現異常。可以在console視窗看到呼叫出現大量異常：
將jmeter的壓測報告進行匯出之後，可以看到呼叫成功率大大降低，
也僅僅只有10%左右的請求能夠被成功處理，這樣的服務假設進行了執行緒池引數優化之後又會如何呢？
1秒鐘100個請求併發訪問dubbo服務，此時業務執行緒池專心只處理服務呼叫的請求，並且最大執行緒數為100，服務端最大可接納連線數也是100，按理來說應該所有請求都能正常處理
dubbo.protocol.threadpool=fixed
dubbo.protocol.dispatcher=execution
dubbo.protocol.threads=
100dubbo.protocol.accepts=
100
ps：提出乙個小問題，從測試報告中檢視到平均介面的響應耗時為：502ms，也就是說其實dubbo介面的承載能力估計還能擴大個一倍左右，我又嘗試加大了壓測的力度，這次看看1秒鐘190次請求會如何？（假設執行緒池100連線中，每個連線對請求的處理耗時大約為500ms，那麼一秒時長大約能處理2個請求，但是考慮到一些額外的耗時可能達不到理想狀態那麼高，因此設定為每秒190次（190 <= 2*100）請求的壓測）
但是此時發現請求的響應結果似乎並沒有這麼理想，這次請求響應的成功率大大降低了。
其實主要原因是當執行緒池滿了的時候，服務會立馬進入失敗狀態，而jmeter產生的壓測執行緒數目並不是均勻的，可能190個執行緒的80%是在1s內的後0.5s中產生，這種情況下是會造成dubbo服務承載失敗的。
執行緒池引數調優
threadpoolexecutor threadpoolexecutor建構函式的五大引數 public threadpoolexecutor int corepoolsize,int maximumpoolsize,long keepalivetime,timeunit unit,blockin...
Dubbo常用調優引數
dubbo是阿里開源的一款流行的分布式服務框架，有必要了解其常用調優引數 引數名作用範圍預設值說明備註 threads provider 200業務處理執行緒池大小 iothreads provider cpu 1 io執行緒池大小 queues provider 0執行緒池佇列大小，當執行緒池滿時...
Hive實戰效能調優
hive是乙個資料倉儲基礎工具在hadoop中用來處理結構化資料。它架構在hadoop之上，總歸為大資料，並使得查詢和分析方便。並提供簡單的sql查詢功能，可以將sql語句轉換為mapreduce任務進行執行。hive 構建在基於靜態批處理的hadoop 之上，hadoop 通常都有較高的延遲並且在...