效能調優通常遵循以下步驟：

• 出現效能問題
• 有經驗的人知道可能是什麼原因，並提出具體的建議
• 確定基準效能，應用更改，然後再次測量效能
• 如果與基準相比效能有所改善，請保留更改，否則恢復更改
• 如果現在認為效能已經足夠，那麼您就完成了。如果不是，請返回有經驗的人員，詢問下一步要做的更改，然後重複上述步驟

這整個過程可能很昂貴。尤其是在複雜的環境中，有經驗的人的建議通常是（很有希望）提供的猜測。這可能需要進行一些迭代才能使效能充分。如果您可以通過增加這種明智的判斷來使這些猜測更加準確，則可能會更有效地進行調整。

在這篇部落格文章中，我將嘗試做到這一點。當然，這裡主要免責宣告適用，因為每個應用程式，環境，硬體等都是不同的。績效的定義以及如何衡量績效也是您可能會有不同意見的地方。簡而言之，我所做的工作是研究許多不同的變數，並針對這些變數的每種組合來測量響應時間和最小化微服務實現的吞吐量。我將所有資料提供給機器學習模型，並詢問該模型用於預測效能的變數。我還在英國布萊頓的UKOUG Techfest 2019上就此主題進行了演講。您可以在此處檢視演示  。

方法

• 在10個框架中編寫了類似的最小hello世界，例如實現（請參見此處的程式碼  ）
• 改變分配核心的數量
• 改變了JVM可用的記憶體
• 改變了Java版本（8,11,12,13）
• 各種JVM風格（OpenJ9，Zing，OpenJDK，OracleJDK）
• 改變了垃圾收集演算法（嘗試了每個JVM /版本的所有可能演算法）
• 改變併發請求的數量

我測量了每種可能的變數組合的響應時間和吞吐量。您可以在此處檢視資料  。

接下來，我將所有資料放入隨機森林迴歸模型中，確認它是準確的，並要求該模型為我提供功能上的重要性。在確定響應時間和吞吐量的生成模型中，哪個功能最重要。這些都是首先要進行調整的功能。具有較低特徵重要性的特徵不那麼相關。當然，正如我已經提到的，該模型是根據我提供的資料生成的。我必須做出一些選擇，因為即使使用20s的測試，每個組合的測試也要花一週的時間。當檢視測試方案以外的情況時，模型的準確性如何？我不能說; 你必須自己檢查。

為什麼使用隨機森林迴歸？

• 它易於使用，適合我的資料。（監督學習）迴歸模型，在偏差和方差之間具有適當的平衡。
• 可以輕鬆確定功能的重要性
• 我還嘗試了支援向量迴歸，但即使接近隨機森林迴歸也無法獲得準確性。對我來說，這是SVR裝備不足的標誌；該模型無法捕獲資料中的模式

我使用了哪些工具？

我當然可以寫一本關於這項研究的書。使用的方法的細節，解釋所有測試的不同微服務框架，詳細說明使用的測試工具等。我不會。您可以檢查自己的指令碼，  在這裡  ，我已經寫了大部分資料的文章  在這裡

• 我使用  Apache Bench  進行負載生成。在某些人看來，Apache Bench可能沒有得到很高的評價，但它做得很好。至少比我先用Node寫的自定義程式碼好，然後再用Python重寫的自定義程式碼更好。例如，將負載生成的效能與wrk進行比較時  ，並沒有太大的區別，只是在更高的併發性上，這超出了我所測量的範圍（請參閱  此處）。為了將來的測試，我將嘗試wrk。
• 我使用Python來執行不同的場景。比我以前使用的Bash更容易。
• 為了分析和視覺化資料，我使用了Jupyter Notebook。
• 在開始實際測試之前，我首先做了一些預熱/灌注
• 我特別注意不要使用VirtualBox或Docker等虛擬化工具
• 即使我在與產生負載的硬體相同的硬體上進行了測量，我也特別著眼於避免資源競爭。將負載生成和服務分配給不同的機器是行不通的，因為有時效能差異很小（不到毫秒）。通過網路進行傳輸時，這些差異將丟失。

結果

在下面的圖中，我顯示了預測值與實際值的對比。對角線表示完美的精度。如您所見，該模型的準確性很高。同樣，響應時間和吞吐量的R ^ 2值（確定係數）都約為0.99，這非常好！

功能重要性

對Java程式的吞吐量影響最大的是框架選擇，其次是JVM版本，併發性和GC演算法，最後是分配記憶體和Java版本以及CPU，說明硬體對程式的吞吐量影響最小。

對Java程式的響應時間也就是延遲影響最大的也是框架選擇，其次是JVM版本以及GC演算法，分配的記憶體，其次是Java版本、併發性和CPU，可見併發性只是對Java吞吐量提高，對響應時間有影響。

總結

選擇的框架的重要性最高。這表明在響應時間和吞吐量方面，實現的選擇（當然在我的測試範圍內）比JVM供應商（Zing，OpenJ9，OpenJDK，OracleJDK）更重要。JVM供應商位元定垃圾收集演算法的選擇更重要（垃圾收集演算法似乎根本沒有那麼重要，即使記憶體受到限制時，垃圾收集演算法似乎也變得越來越重要）。Java版本選擇對這兩個指標沒有太大差異。

最不重要的是分配的CPU核心數。顯然，分配更多的核心並不能改善效能。因為我發現這很奇怪，所以我對資料進行了一些額外的分析，並且發現某些框架在使用更多核心或處理更高的併發性方面比其他框架更好（當不使用預設設定專門調整單個框架/ HTTP伺服器時）。

下圖是在單個CPU上一個請求和4個請求的吞吐量，沒有框架使用是最高的，其實是Vertx，Spring Boot和Quarkus墊底：

下圖是一個CPU無併發和4個CPU4個併發請求的吞吐量，除了SPring Boot WebFlux上升到中位以後，其他沒有變化。

下圖是在單個CPU上一個請求和4個請求的響應時間：Quarkus從吞吐量的墊底排名到第一名，順序基本是吞吐量排名的顛倒，說明高吞吐量和低延遲的矛盾:

下圖是一個CPU無併發和4個CPU4個併發請求的響應時間：Spring Boot Webflux從第三名下落到第五名，被Akka替代。

Micronaut在吞吐量和響應時間方面無論是單CPU還是多CPU並發表現都是中位，在吞吐量和響應時間之間平衡。

您可以在這裡檢查筆記本  。