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

但是有時(shí)候，從您的駱駝路線中擠出幾毫秒可能是值得的。 調(diào)整每個(gè)應(yīng)用程序非常具體，并且取決于技術(shù)和用例。 這里有一些關(guān)于調(diào)整基于駱駝的系統(tǒng)的想法，這些想法可能適用于您（或不適用）。

端點(diǎn)調(diào)整

Camel中的端點(diǎn)是與其他系統(tǒng)的集成點(diǎn)，它們的配置方式將對系統(tǒng)的性能產(chǎn)生巨大影響。 了解不同端點(diǎn)的工作方式并進(jìn)行調(diào)整應(yīng)該是最開始的地方之一。 以下是一些示例：

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

數(shù)據(jù)類型選擇

通過駱駝路線傳遞的數(shù)據(jù)的類型和格式也將影響性能。 為了證明這一點(diǎn)，讓我們看幾個(gè)例子。

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

  基于不同數(shù)據(jù)類型的基于內(nèi)容的路由

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

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

多線程

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

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

  并行文件消耗

• Seda組件 – Seda是在駱駝中實(shí)現(xiàn)并行性的另一種方法。 Seda組件具有內(nèi)存中列表，用于累積來自生產(chǎn)者和并發(fā)消費(fèi)者的傳入消息，以通過多個(gè)線程并行處理這些傳入請求。
• 異步重新傳送/重試–如果在路由過程中使用帶有重新傳送策略的錯(cuò)誤處理程序，則可以將其配置為異步并在單獨(dú)的線程中進(jìn)行重新傳送。 這將使用單獨(dú)的線程池進(jìn)行重新交付，而不會(huì)在等待時(shí)阻塞主請求處理線程。 如果您需要長時(shí)間延遲的重新交付，使用ActiveMQ代理重新交付（與消費(fèi)者重新交付BTW不同）可能是更好的方法，因?yàn)橹匦陆桓秾⒈Ａ粼谙⒋砩?#xff0c;而不保存在Camel應(yīng)用程序內(nèi)存中。 這種機(jī)制的另一個(gè)好處是重新交付將在應(yīng)用程序重新啟動(dòng)后繼續(xù)存在，并且在集群應(yīng)用程序時(shí)也可以很好地播放。 我在《 駱駝設(shè)計(jì)模式》一書中描述了不同的重試模式。

其他優(yōu)化

您可以采取其他一些技巧來進(jìn)一步微調(diào)Camel。

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

應(yīng)用設(shè)計(jì)

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

虛擬機(jī)

關(guān)于JVM調(diào)優(yōu)的文章很多。 在這里，我只想提及Red Hat的JVM配置生成應(yīng)用程序。 只要您擁有Red Hat帳戶（無論如何對開發(fā)人員都是免費(fèi)的），就可以使用它。

操作系統(tǒng)

您只能擠壓應(yīng)用程序那么多。 為了進(jìn)行適當(dāng)?shù)母哓?fù)載處理，也必須調(diào)整主機(jī)系統(tǒng)。 要了解各種操作系統(tǒng)級別選項(xiàng)， 請查看 Jetty項(xiàng)目中的以下檢查清單 。

結(jié)論

本文只是為了給您一些想法，并向您展示在必須提高Camel應(yīng)用程序性能時(shí)要考慮的可能領(lǐng)域的擴(kuò)展。 無需尋找神奇的配方或通過核對表，而應(yīng)進(jìn)行測量支持的小幅增量更改，直到達(dá)到所需狀態(tài)為止。 與其關(guān)注微優(yōu)化和黑客，不如對系統(tǒng)有一個(gè)整體的了解，正確地進(jìn)行設(shè)計(jì)，然后從主機(jī)系統(tǒng)開始進(jìn)行調(diào)優(yōu)，以適應(yīng)JVM，CamelContext，路由元素，端點(diǎn)和數(shù)據(jù)本身。

使用眾所周知的模式，原理和實(shí)踐，著重于簡單且可擴(kuò)展的設(shè)計(jì)是一個(gè)好的開始。 祝好運(yùn)。

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

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。