基於等待的調優方法
建好了負載測試，接下來就是決定把調優精力放在何處。大多數調優指南都會提到「效能比率」或者度量之間的關係。例如，某調優指南可能強調說快取命中率應該達到80%或者更高，因此負載測試應用時調整快取大小直到命中率達到80%.然後處理列表上的下乙個度量值，但是不要忘記驗證調整新的引數不會影響之前已經調好的其他引數。
這項工作不僅困難而且效率很低。例如，調整快取命中率到80%可能是件好事，但是存在一些更重要的問題：
● 該應用如何依賴於快取（與該快取互動的請求比例是多少）？
● 這些請求對應用中的其他請求有多大影響力？
● 被快取的條目的本質是什麼？它們真的需要快取嗎？
基於等待的調優方法提出了乙個新的思想，即分析應用的業務互動和實現這些互動的底層結構，然後優化這些業務互動的處理。第一步是分析應用的架構以定位實現業務請求的相關技術。每乙個技術代表乙個「等待點」，或者說在應用的這個地方，請求可能需要等待一些事情才能繼續處理。例如，如果乙個請求執行了一次資料庫查詢，則它必須從連線池中獲取乙個資料庫連線—如果連線池裡沒有可用的連線，則該請求必須等待直到有連線可用。同樣，如果某請求呼叫了乙個web服務，而那個web服務維護了乙個請求佇列（對應乙個執行緒池處理請求），這會潛在的導致請求等待直到乙個處理執行緒可用。
從以上稱之為等待點分析的方法中，可以定位兩種型別的等待點：
● 基於層次的等待點
● 基於技術的等待點
本節首先概述了基於等待點的架構分析方法，然後分別研究了不同型別的等待點。
等待點架構分析
從上面討論中得出的最重要的結論就是效能調優必須在應用架構的環境中執行。這也是調優效能比率為何如此低效的乙個原因：主觀的調整乙個效能引數到乙個最佳值，對應用可能是好事也可能是壞事——因為這可能會也可能不會有利於終端使用者體驗。
基於等待點的分析是乙個分析應用中主要請求處理路徑的過程，藉此定位潛在影響該請求可能會等待的資源。在等待點分析實踐中最有效的辦法是定位並標出應用中核心處理路徑。這包括乙個請求可能訪問的所有層次、請求互動的所有外部服務、被做成池的所有物件和全部快取物件。
基於層次的等待點
乙個請求穿過乙個物理層，比如在web層和業務層之間切換，或者呼叫外部伺服器 ，比如web服務，每當這種時候，都意味著伴隨著轉換，這裡存在乙個隱式等待點。如果伺服器在某一時刻只處理單個請求是沒有效率的，因此他們使用了多執行緒方法。典型的，乙個伺服器在某個socket埠監聽訪問的請求——每當收到乙個請求它就會把請求放在佇列中，然後返回監聽其他請求。請求佇列對應著乙個執行緒池，負責從佇列中提取請求並處理。圖2描述了對於三層結構（web伺服器、動態web層和業務層）的執行過程。
圖 2 基於層次的等待點
因為請求穿越層次的動作會引起請求佇列，由相應的執行緒池處理，這種執行緒池也是乙個潛在的等待點。每乙個執行緒池的大小的調優必須基於以下考慮：
● 池必須足夠大使得訪問的請求無需不必要的等待乙個執行緒。
● 池不能大到耗盡伺服器。過多的執行緒會迫使伺服器花費大量時間用於在不同的執行緒上下文中切換，真正處理請求的時間反而更少了。這種情況通常表現為cpu使用率很高，但是處理請求的吞吐量卻降低了。
● 池的大小不能透支與之互動的後台資源。例如，如果資料庫對於單個伺服器只支援50個請求，那麼伺服器不應該向資料庫傳送超過50個數量的請求。
Java中基於等待的調優方法詳解 3
基於等待的調優方法 建好了負載測試，接下來就是決定把調優精力放在何處。大多數調優指南都會提到 效能比率 或者度量之間的關係。例如，某調優指南可能強調說快取命中率應該達到80 或者更高，因此負載測試應用時調整快取大小直到命中率達到80 然後處理列表上的下乙個度量值，但是不要忘記驗證調整新的引數不會影響...
oracle 效能調優之等待事件統計
等待事件統計 等待事件是通過會話增量累計的用力表示會話在它能夠繼續執行以前等待乙個事件完成。當乙個會話處理乙個使用者請求必須等待時，資料庫記錄通過使用一系列預先定義的等待事件來等待。這是事件按照等待級別分組，就像使用者i o和網路。等待事件資料 揭露可能影響資料庫效能的症狀。就像鎖啊，快取或者i o...
spark效能調優 本地化等待時長
本地化級別 1.程序本地化 2.節點本地化 3.機架本地化 4.any 都沒有 但是，通常來說，有時候，事與願違，可能task沒有機會分配到它的資料所在的節點，可能那個節點的計算資源和計算能力都滿了，所以，這種時候，通常倆說，spark會等待一段時間，預設情況下是3s 不是絕對的，還有很多情況，對不...