activiti異步執(zhí)行

一點歷史

永無休止的一件事是，Activiti在某些非常大的規(guī)模的大型組織中的使用方式。 過去，這導(dǎo)致了各種優(yōu)化和重構(gòu)，其中包括異步執(zhí)行器-替換舊的作業(yè)執(zhí)行器。 對于未啟動的用戶：這些執(zhí)行器在流程實例中處理計時器和異步繼續(xù)。 特別是在過去的兩年中，我們已經(jīng)看到它的使用大大增加。 異步執(zhí)行器的引入極大地提高了性能。 但是，去年在巴黎舉行的社區(qū)活動中，我們了解到，在處理大量工作時，執(zhí)行者使用的查詢可能會導(dǎo)致需要進行表掃描。 這永遠不是一件好事。

因此，我們知道在完成版本6之前，我們確實想做一件事，那就是重構(gòu)異步執(zhí)行器，使它使用的所有查詢都變得非常簡單。 這確實意味著我們必須將作業(yè)數(shù)據(jù)拆分為與不同類型和狀態(tài)匹配的各種表，同時仍要使API與以前的Activiti版本兼容。

在過去的幾個月中，我們一直在做這些事情（包括許多其他事情），并取得了一些不錯的結(jié)果以及一些新的不錯的API，這些API豐富了該平臺。 我可以在“新的”異步執(zhí)行程序的工作方式上寫另一個博客，但是昨天我已經(jīng)完成了文檔工作，因此，如果您對所有工作方式都感興趣， 請查看在線文檔或檢查工具 欄上 的源代碼。 v6分支 。

架構(gòu)設(shè)計當然受我們從過去兩種實現(xiàn)中學(xué)到的知識的影響，但同時也受消息隊列系統(tǒng)中概念的影響很大。 設(shè)計目標之一是插入消息隊列并運行它應(yīng)該非常容易，因為我們有一種直覺，認為這將對性能有所幫助。

因此，我們做到了。 由于新的體系結(jié)構(gòu)，使異步執(zhí)行程序與消息隊列一起工作幾乎是微不足道的。 如果您對實現(xiàn)感興趣， 我還會在文檔中添加有關(guān)此主題的部分。

而且，當然，您知道我，我只是想將這兩個執(zhí)行程序?qū)崿F(xiàn)相互比較基準＆＃55357;＆＃56898;

基準項目

您可以找到我在Github上使用的代碼： https : //github.com/jbarrez/queue-based-async-executor-benchmark

基本上，它的操作是使用配置屬性文件運行Main.java。

• 使用適當?shù)呐渲脝恿鞒桃?#xff08;我最近在網(wǎng)上看到一些Activiti基準測試，這些基準在不使用適當?shù)倪B接池數(shù)據(jù)源的情況下對Activiti的性能進行了基準測試。
• 如果以“生產(chǎn)者”身份運行，將啟動10000個流程實例，每10毫秒一個。 定期的統(tǒng)計信息將被打印到控制臺上。
• 如果以“執(zhí)行程序”身份運行，則將流程引擎配置為啟用異步執(zhí)行程序。
• 可以有任意數(shù)量的生產(chǎn)者/執(zhí)行者，但是所有生產(chǎn)者/執(zhí)行者都進入同一個數(shù)據(jù)庫。

項目中使用的流程定義如下：

需要注意的重要一點（在圖中不可見）是，在此重要的流程定義中，所有服務(wù)任務(wù)都是異步的。 并行派生之后的服務(wù)任務(wù)與加入的并行網(wǎng)關(guān)一樣配置為互斥的 。 這里有兩個計時器，其中用戶任務(wù)上的一個是1秒，子流程上的一個是50分鐘。 總而言之，當啟動流程實例時，它導(dǎo)致需要執(zhí)行27個作業(yè)才能到達終點。 對于10000個實例，這意味著我們正在有效測試270 000個作業(yè)的吞吐量。

請注意，與任何基準測試一樣，原始數(shù)據(jù)說明了一切，但不是全部。 這一切都取決于服務(wù)器硬件，實際的流程定義和許多其他細節(jié)。 但是，如果在完全相同的硬件上執(zhí)行完全相同的代碼，相對數(shù)字會給我們帶來很多啟發(fā)。 閱讀下一部分時，請記住這一點。

測試環(huán)境

所有基準測試都是在Amazon Web Services（AWS）上運行的，生產(chǎn)者/執(zhí)行者使用EC2服務(wù)器，r3.4xlarge（16個vCPU，16個vCPU）上的數(shù)據(jù)庫使用RDS PostgresQL （因為Postgres是一個很棒的數(shù)據(jù)庫，非常容易設(shè)置） 122 GiB內(nèi)存）。

使用以下EC2配置

• RDS（postgres）：r3.4xlarge（16個vCPU，122 GiB內(nèi)存）
• 生產(chǎn)者引擎：c3.4xlarge（16個vCPU，30 GiB內(nèi)存）
• 執(zhí)行器引擎：c3.8xlarge（32個vCPU，60 GiB內(nèi)存）

所有服務(wù)器都在歐盟西部地區(qū)運行。 因此，所有測試結(jié)果都具有真實的網(wǎng)絡(luò)延遲（沒有運行在localhost基準測試上的延遲，因此跳過了網(wǎng)上經(jīng)?？吹降穆?lián)網(wǎng)）。 當運行上面的項目時，JVM分配了8GB的空間。

我們將使用的指標是作業(yè)的吞吐量 ，以作業(yè)/秒表示。 簡而言之，在測試運行之后，我們驗證數(shù)據(jù)庫中的數(shù)據(jù)是否正確（即10K完成的流程實例），并采用第一個開始時間和最后一個結(jié)束時間，這使我們獲得了x秒的時間。 則吞吐量為x / 270000（眾所周知，每個流程實例等于27個作業(yè)）。

基線測量

基準測試的第一件事是“基準”，即由線程池支持的常規(guī)異步執(zhí)行程序（即v5中異步執(zhí)行程序的改進設(shè)計）。 在此測試中，我們使用了2臺服務(wù)器，并進行了以下配置（注意：6.0.0.Beta3實際上是快照版本）：

	一個	乙	C	d
Activiti版本	6.0.0.Beta3	6.0.0.Beta3	6.0.0.Beta3	5.21.0
生產(chǎn)者引擎	1個	1個	1個	1個
執(zhí)行器引擎	1個	1個	2	2
＃池中的線程	32	10	10	10
阻塞隊列大小	256	100	100	100

一些有趣的觀察：

我認為配置A會比配置B更好，因為這臺機器畢竟有32個CPU，因此將線程池的線程數(shù)與此匹配是合理的。 但是，配置B的設(shè)置非常相似，除了只有10個線程和較小的阻塞隊列之外，它的性能大大提高（310 vs 210作業(yè)/秒）。 一個可能的解釋可能是32個線程爭用太多？ 我確實記得當初選擇默認值“ 10”時，我們進行了一些基準測試，其中10是吞吐量最佳的“魔術(shù)數(shù)字”（但我認為這取決于所使用的機器。）

我希望添加另一個執(zhí)行程序節(jié)點會產(chǎn)生更大的影響，畢竟我們要添加32個CPU的計算機，但是收益很小（310到326）。 我們將學(xué)習(xí)原因，并在本文的稍后階段進行修復(fù)。

使用Activiti版本5.21.0的配置D使用與配置C相同的設(shè)置。但是，改進的版本6的異步執(zhí)行程序顯然在這里勝出（326 vs 266）。 這當然是我們希望的：-)。

到目前為止，我們最好的結(jié)果是每秒326個作業(yè) （并使用兩臺服務(wù)器）。

基準線的變化

鑒于以上設(shè)置，可以詢問運行混合的生產(chǎn)者/執(zhí)行者時產(chǎn)生的影響。 這是Activiti引擎默認的運行方式：引擎將同時負責啟動流程實例并立即執(zhí)行它們。 這是配置E （與配置C相同，除了兩個引擎現(xiàn)在都是生產(chǎn)者/執(zhí)行者），結(jié)果如下所示。 而且顯然性能較差。 一種解釋可能是該機器已經(jīng)每10毫秒使用10個線程來啟動流程實例，這可能導(dǎo)致與異步執(zhí)行器的10個線程相當多的爭用。 可能可以對該設(shè)置進行很多調(diào)整以獲得更好的數(shù)字，但這不是此博客的目標。 但是結(jié)果仍然很有趣。

因此，考慮到兩個執(zhí)行器引擎勝于一個執(zhí)行器引擎，合乎邏輯的事情是嘗試三個執(zhí)行器。 這是配置F。

類似于從一個執(zhí)行程序到兩個執(zhí)行程序，吞吐量提高了。 但不是以一種壯觀的線性方式。

介紹基于消息隊列的異步執(zhí)行器

現(xiàn)在該切換到基于消息隊列的異步執(zhí)行器了，現(xiàn)在我們有了基準編號。 我選擇了最新版本的ActiveMQ ，因為我對此很熟悉，并且設(shè)置起來非常容易。 我沒有花時間調(diào)整ActiveMQ，切換持久性策略或嘗試替代方法。 因此，那里也可能會有一些利潤。

在基準項目中，我將Spring與以下配置一起使用： https : //github.com/jbarrez/queue-based-async-executor-benchmark/blob/master/src/main/java/org/activiti/MyConfigMessageExecutor.java 。 之所以選擇Spring，是因為MessageListenerContainer提供了一種簡單的方法來使消息隊列偵聽器可以很好地與多個線程一起工作（JBoss這樣的應(yīng)用程序服務(wù)器可以為您提供其他功能）。 更具體地說，MessageListenerContainer的concurrenConsumers設(shè)置允許設(shè)置用于以智能方式監(jiān)聽消息的線程數(shù)。 是的，此類確實具有許多可能會更好地影響結(jié)果的屬性，但這又不是重點。 請記住相對數(shù)字。

對于此配置，我們使用與config C類似的設(shè)置（到目前為止，我們在兩臺服務(wù)器上的最佳結(jié)果），稱為config G：1個生產(chǎn)者引擎，2個執(zhí)行者引擎。 請注意，我們現(xiàn)在還在混合中添加了“隊列服務(wù)器”，它使用的是c3.8xlarge機器（32個vCPU，60 GiB RAM），類似于執(zhí)行引擎服務(wù)器。

結(jié)果在下面…簡直太棒了：在等效設(shè)置（但帶有額外的消息隊列服務(wù)器）中的消息隊列異步執(zhí)行程序比基于線程池的異步執(zhí)行程序快四倍 。

一個小的實現(xiàn)說明：我們不得不切換到UUID ID生成器 ，因為吞吐量對于默認值而言太高了。 請記住，UUID生成器比默認生成器慢，結(jié)果甚至更棒（因為我們在這里實際上談?wù)摰氖呛撩?#xff09;。

有趣的觀察！

如果您運行基準測試項目，則會看到它會定期吐出一些統(tǒng)計信息，以便您可以跟蹤系統(tǒng)中有多少作業(yè)，計時器，用戶任務(wù)，歷史活動實例，流程實例等。

在運行消息隊列設(shè)置時，從這些數(shù)字中可以很清楚地看出一種模式。 基于線程池的異步執(zhí)行器可以更快地完成流程實例（例如，大約1分鐘后，我們看到一批流程實例已完成），而對于基于消息的異步執(zhí)行器，流程實例實際上都是在最后一次大爆發(fā)中完成的。 這表明后者將更多地分散流程實例活動的執(zhí)行，而基于線程的活動將繼續(xù)進行直到完成為止。

團隊中的一些討論導(dǎo)致了對此的解釋：基于線程池的線程將始終將下一個異步作業(yè)傳遞給執(zhí)行器，而基于消息的線程則將其放在隊列中，那里已經(jīng)有數(shù)千條消息在等待。 現(xiàn)在添加一個事實，我們對流程實例有很多排它異步作業(yè)，這意味著對于基于線程池的異步作業(yè)，許多線程試圖獲取流程實例鎖，但是由于執(zhí)行了排他異步操作而失敗。 但是，這項工作沒有獲得 ，很快就重新開始了。 對于基于消息隊列的消息隊列，將它們再次添加到消息隊列的末尾。 其中有數(shù)千條其他消息正在等待。 回到執(zhí)行此特定消息時，排他鎖很可能已經(jīng)很久了。

這導(dǎo)致在基于線程池的異步執(zhí)行程序中進行一些重構(gòu)：刪除并重新插入作業(yè)，而不是簡單地釋放作業(yè)的鎖定，從而有效地模擬了隊列行為。 這是修復(fù)程序： https : //github.com/Activiti/Activiti/commit/d08a247570336c872bb17ce513c1fb95b3ba47a2#diff-bd9c7efdb4c57462f6fe71641b280942R212 。

在與config C完全相同的設(shè)置（稱為config H（1個生產(chǎn)者，2個執(zhí)行者））中對這些基準進行基準測試，這表明我們此簡單的解決方案將吞吐量提高了34％！ 現(xiàn)在我們有了一個新的基準

更好的消息隊列異步執(zhí)行器結(jié)果

因此，在消息隊列結(jié)果（配置G）中，我們使用了10個線程的相當保守的設(shè)置來偵聽消息。 想法是我們還有10個線程池用于線程池。 當然，消息隊列使用者從根本上不同于輪詢線程：此類使用者與隊列具有持久連接，而隊列代理實際上將工作推給其使用者。 這應(yīng)該更有效。 因此，我們嘗試了以下配置，在這些配置中，我們改變了使用者（從而消耗了線程）和執(zhí)行程序節(jié)點的數(shù)量。

	一世	?	?	大號
生產(chǎn)者引擎	1個	1個	1個	1個
執(zhí)行器引擎	2	2	3	3
＃消費者/引擎	32	64	32	64

因此，一個不錯的觀察結(jié)果是，添加更多的消費者是超級有效的。 我們正在達到2222.9作業(yè)/秒的吞吐量 。 如果您問我，那是極快的速度，是基于線程池的異步執(zhí)行器的五倍。

可悲的是，將更多的執(zhí)行器機器添加到組合中實際上對性能不利。 我認為瓶頸現(xiàn)在已成為數(shù)據(jù)庫，以及它如何處理大規(guī)模進行的所有并發(fā)。 當然，我根本不調(diào)整數(shù)據(jù)庫 ，而只是常規(guī)RDS postgres實例。 或嘗試使用Aurora或Oracle（在我以前的基準測試中獲得最好的結(jié)果）。 但是，這里的重點是相對數(shù)量 ，而不是擠出吞吐量的最后一部分。 我認為相對數(shù)字點已經(jīng)確定為＆＃55357;＆＃56898;

結(jié)論

數(shù)字說明了一切：基于新消息隊列的異步執(zhí)行器擊敗了基于線程池的異步執(zhí)行器。 這是否意味著您必須立即切換？ 不， 常規(guī)的異步執(zhí)行器也非?？?#xff08;每秒436作業(yè)仍然很快），但是更重要的是，設(shè)置非常簡單，因為Activiti引擎可以處理所有事情。 在項目中添加消息隊列意味著更多的復(fù)雜性：可能會失敗或崩潰的另一件事，額外的監(jiān)視，維護等。但是，當您執(zhí)行大量 （我的意思是“很多”）異步工作時，您會重新達到默認異步執(zhí)行器可以執(zhí)行的操作的限制，很高興知道還有替代方法。

我們還要忘記這里得出的另一個結(jié)論：版本6中的新異步執(zhí)行程序?qū)崿F(xiàn)是對版本5的重大改進！

進一步的工作

當前的實現(xiàn)僅是Spring / JMS。 但是，該實現(xiàn)很容易移植到其他系統(tǒng)和/或協(xié)議（應(yīng)用程序服務(wù)器，STOMP，AMPQ，AWS SQS等）。 對于將成為流行的下一個選擇的反饋，我們深表感謝。

有趣的是，這種基于消息隊列的異步執(zhí)行器使實現(xiàn)“優(yōu)先級隊列”非常簡單。 優(yōu)先級隊列是我們許多大型用戶所要求的功能：提供特定的流程定義/實例/在特定條件下/ ...優(yōu)先級與常規(guī)作業(yè)相比。 容易想象如何設(shè)置多個隊列和/或分配更少或更多的使用者以賦予某些用例優(yōu)先級。

翻譯自: https://www.javacodegeeks.com/2016/07/benchmarking-message-queue-based-activiti-async-executor.html

activiti異步執(zhí)行

總結(jié)

以上是生活随笔為你收集整理的activiti异步执行_对基于消息队列的Activiti异步执行器进行基准测试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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