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