時不時地，我會以Camel速度較慢的說法來詢問有關優化Camel應用程序的問題。 駱駝只是連接不同系統的粘合劑，路由引擎全都在內存中，并且不需要任何持久狀態。 因此，在99％的情況下，性能問題是由于其他系統的瓶頸所致 ，或者是在沒有性能考慮的情況下完成了應用程序設計。 如果真是這樣，那么進一步調整Camel并沒有太大的作用，您必須回到繪圖板上。

但是有時候，從您的駱駝路線中擠出幾毫秒可能是值得的。 調整每個應用程序非常具體，并且取決于技術和用例。 這里有一些關于調整基于駱駝的系統的想法，這些想法可能適用于您（或不適用）。

端點調整

Camel中的端點是與其他系統的集成點，它們的配置方式將對系統的性能產生巨大影響。 了解不同端點的工作方式并進行調整應該是最開始的地方之一。 以下是一些示例：

• 消息傳遞 –如果您的Camel應用程序正在使用消息傳遞，則總體性能將在很大程度上取決于消息傳遞系統的性能。 這里有太多因素需要考慮，但主要因素有：
• • 消息代理 –網??絡和磁盤速度以及代理拓撲將決定代理性能。 為了給您一個想法，使用ActiveMQ，基于關系數據庫的持久性存儲將執行約50％的基于文件的存儲，而使用代理網絡進行水平擴展將又花費30％的性能。 令人驚訝的是，ActiveMQ中的一項配置更改如何對消息傳遞系統以及Camel應用程序產生巨大影響。 必須閱讀Red Hat的ActiveMQ 調優指南 ，其中包含許多要考慮和評估的細節。 克里斯蒂安·波斯塔 （ Chrisitan Posta）的現實生活中的一個例子，展示了在某些情況下如何使經紀人加速25倍 。
  • 消息客戶端 –如果將性能放在首位，則可以在ActiveMQ客戶端上進行一些黑客操作，例如：增加TCP socketBufferSize和ioBufferSize，調整OpenWire協議參數，使用消息壓縮，批處理確認 與optimizeAcknowledge，異步發送與useAsyncSend，調整預取極限，等有克里斯蒂娜又都是一些不錯的幻燈片這里老，但仍然非常相關的視頻由羅布·戴維斯有關調整的ActiveMQ。 所有這些資源都應該為您提供足夠的想法，以便從消息的角度進行實驗并提高性能。
• 數據庫寫入 –盡可能使用批處理。 在執行批處理操作以與數據庫（例如與SQL組件）進行交互之前，可以使用聚合器收集大量條目。 return new RouteBuilder() {public void configure() throws Exception {from("direct:start").aggregate(header("PROD_TYPE"), new SQLStrategy()).completionSize(100).completionTimeout(1000).to("sql:insert into products (price, description) values (#, #)?batch=true");} };
• 對模板的使用 -如果你必須使用模板組件作為路由的一部分，嘗試在現有的模板引擎（FreeMarker的，速度，SpringTeplate，小胡子，組塊）與一個小的測試為以下一個和衡量哪一個性能更好。 克里斯蒂安·穆勒（Christian Mueller）在題為“ 駱駝的性能優化”的演講中做了出色的介紹，其中的源代碼支持了這一發現。 通過這些測量，我們可以看到 FreeMarker的性能通常比Velocity和SprintTemplates好。
• 使用Web服務 –每當需要使用Web終結點時，Web容器本身（必須分別進行調整。從Camel終結點的角度來看，如果不需要Java對象，則可以通過跳過解組來進一步優化一點，并使用異步處理。
• parallelConsumers –有許多支持并行使用的組件（Seda，VM，JMS，RabbitMQ，Disruptor，AWS-SQS等）。 使用端點之前，請檢查組件文檔中的線程池或批處理功能。 為了讓您有個想法，請參閱如何通過這些選項來改進 Amzon SQS處理。

數據類型選擇

通過駱駝路線傳遞的數據的類型和格式也將影響性能。 為了證明這一點，讓我們看幾個例子。

• 基于內容的路由器，分離器，過濾器是基于消息內容執行某些工作的EIP的示例。 消息的類型會影響這些元素的處理速度。 以下是克里斯蒂安·穆勒（Christian Mueller）的演示文稿中的圖表，可視化了基于內容的路由器如何處理各種消息：
  
  

  基于不同數據類型的基于內容的路由

  例如，如果您在Exchange中有一個大型XML文檔，并基于該文檔執行基于內容的路由，篩選等操作，則這將影響路由的速度。 相反，您可以從文檔中提取一些關鍵信息，并填充Exchange標頭，以便以后更快地訪問和路由。

• 封送處理/取消封送處理 –與模板引擎類似，不同的數據格式venvenor表現也不同。 要查看一些指標，請再次檢查Christian的演示文稿，但也要記住， 受支持的數據格式的性能在不同版本和平臺之間可能會有所不同，因此請針對您的用例進行衡量。
• 流 -駱駝流和流緩存是被低估的功能之一，可用于處理大消息。
• 聲明檢查EIP –如果應用程序邏輯允許，請考慮使用聲明檢查模式來提高性能并減少資源消耗。

多線程

Camel在許多地方都提供了多線程支持。 使用這些也可以提高應用程序性能。

• 并行處理EIP –以下駱駝EIP實現支持并行處理–多播，收件人列表，拆分器，延遲器，竊聽，調節器，錯誤處理程序。 如果您要為它們啟用并行處理，最好還提供一個針對您的用例進行了專門調整的自定義線程池，而不是依賴于Camel的默認線程池配置文件。
• 線程DSL構造 –某些Camel終結點（例如文件使用者）在設計上是單線程的，無法在終結點級別并行化。 對于文件使用方，單個線程一次選擇一個文件，并通過路徑處理該文件，直到到達路徑末尾，然后使用方線程選擇下一個文件。 這是駱駝線程構造有用的時候。 如下圖所示，文件使用者線程可以選擇一個文件，并將其從Threads構造傳遞給線程以進行進一步處理。 然后，文件使用方可以選擇另一個文件，而無需等待先前的Exchange完全完成處理。
  
  

  并行文件消耗

• Seda組件 – Seda是在駱駝中實現并行性的另一種方法。 Seda組件具有內存中列表，用于累積來自生產者和并發消費者的傳入消息，以通過多個線程并行處理這些傳入請求。
• 異步重新傳送/重試–如果在路由過程中使用帶有重新傳送策略的錯誤處理程序，則可以將其配置為異步并在單獨的線程中進行重新傳送。 這將使用單獨的線程池進行重新交付，而不會在等待時阻塞主請求處理線程。 如果您需要長時間延遲的重新交付，使用ActiveMQ代理重新交付（與消費者重新交付BTW不同）可能是更好的方法，因為重新交付將保留在消息代理上，而不保存在Camel應用程序內存中。 這種機制的另一個好處是重新交付將在應用程序重新啟動后繼續存在，并且在集群應用程序時也可以很好地播放。 我在《 駱駝設計模式》一書中描述了不同的重試模式。

其他優化

您可以采取其他一些技巧來進一步微調Camel。

• 記錄 配置 –希望您不必在生產環境中記錄每條消息及其內容。 但是，如果必須，請考慮使用一些異步記錄器。 在高吞吐量系統上，可選的方法是通過Camel吞吐量記錄器記錄統計信息和匯總指標。 吞吐量記錄器允許以固定的時間間隔或基于已處理消息的數量而不是每個消息基礎記錄聚合統計信息。 另一個選擇是使用不太流行的Camel Sampler EIP并時不時僅記錄樣本消息。
• 禁用JMX –默認情況下，啟用Camel JMX工具會創建很多MBean。 這不僅可以監視和管理Camel運行時，而且還會降低性能，并需要更多資源。 我仍然記得曾經不得不完全關閉Camel中的JMX以便在一個免費的AWS賬戶上以512MB堆運行它的時候。 至少要考慮是否需要啟用任何JMX，如果需要，則是否要使用RoutesOnly，默認或擴展JMX配置文件。
• 消息歷史記錄 -駱駝實現消息歷史記錄EIP并默認運行它。 在開發環境中，查看每個端點也都有一條消息可能會很有用，但是在生產環境中，您可能考慮禁用此功能。
• 原始郵件 -每條駱駝路線都將在原始郵件復制之前對其進行任何修改。 保留此原始消息副本，以防在錯誤處理期間或使用onCompletion構造重新發送它。 如果不使用這些功能，則可以禁用創建和存儲每個傳入消息的原始狀態。
• 其他自定義 – CamelContext中的幾乎每個功能都可以自定義。 例如，您可以使用lazyLoadTypeConverters來加快應用程序的啟動速度，或者將shutdownStrategy配置為在出現機上消息時更快地關閉，或者使用執行速度更快的自定義UuidGenerator等。

應用設計

與應用程序設計和體系結構相比，所有先前的調優都是微優化。 如果您的應用程序不是為可伸縮性和性能而設計的，那么小型調優黑客遲早會達到其極限。 機會是，您之前所做的事情是在做的，而不是重新發明輪子或提出一些聰明的設計，而是從其他人的經驗中學習并使用眾所周知的模式，原理和實踐。 使用來自SOA的原則，微服務架構，彈性原則，最佳消息傳遞實踐等。其中的某些模式（例如并行管道，CQRS，負載均衡，斷路器）在Camel設計模式一書中進行了介紹，并有助于改善整體應用程序設計。

虛擬機

關于JVM調優的文章很多。 在這里，我只想提及Red Hat的JVM配置生成應用程序。 只要您擁有Red Hat帳戶（無論如何對開發人員都是免費的），就可以使用它。

操作系統

您只能擠壓應用程序那么多。 為了進行適當的高負載處理，也必須調整主機系統。 要了解各種操作系統級別選項， 請查看 Jetty項目中的以下檢查清單 。

結論

本文只是為了給您一些想法，并向您展示在必須提高Camel應用程序性能時要考慮的可能領域的擴展。 無需尋找神奇的配方或通過核對表，而應進行測量支持的小幅增量更改，直到達到所需狀態為止。 與其關注微優化和黑客，不如對系統有一個整體的了解，正確地進行設計，然后從主機系統開始進行調優，以適應JVM，CamelContext，路由元素，端點和數據本身。

使用眾所周知的模式，原理和實踐，著重于簡單且可擴展的設計是一個好的開始。 祝好運。

翻譯自: https://www.javacodegeeks.com/2016/01/performance-tuning-ideas-apache-camel.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的Apache Camel的性能调整思路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。