歡樂表現基準

Question

我們使用歡樂連接從hl7到文本的消息轉換並將轉換後的消息存儲到azure sql數據庫。我們目前的表現是每小時45000消息。機器配置爲 8 GB RAM和2核CPU。分配給歡樂的內存是-XMS = 6122MB

我們對上述配置的Mirth性能參數沒有任何瞭解。任何人都有關於歡樂連接的性能基準的想法？

Answer 1

我們正在使用AWS EC2 4c.4xlarge實例來測試裸骨驗證性能限制。我們得到了大約50 msgs/sec，而在cpu /內存/網絡/磁盤io/db io等方面沒有明顯的瓶頸。希望將限制提高。請分享你的意見，如果有的話。

Answer 2

我建議您查看3.4版及更高版本中的Max Processing Threads選項。它可以在Source Settings（Source選項卡）中配置。默認情況下，它被設置爲1，這意味着只有一個消息可以在任何給定的時間通過通道的主處理線程處理。這對消息順序至關重要的某些接口很重要，但顯然它限制了吞吐量。

請注意，無論客戶端是否發送您的頻道消息也需要重新配置爲並行發送多個消息。例如，如果您有一個單線程進程通過TCP/MLLP依次發送您的通道消息，增加最大處理線程並不一定會幫助，因爲客戶端仍然是單線程的。但是，例如，如果您站起來同時向您的頻道發送的所有客戶端，那麼您肯定會獲得增加最大處理線程的好處。

如果您的源連接器是輪詢類型，例如文件讀取器，您仍然可以通過打開源隊列並增加最大處理線程來獲益。當啓用源隊列並且有多個處理線程時，將啓動多個隊列使用者，並且同時從源隊列讀取和處理所有隊列使用者。

要看的另一件事是目的地排隊。在高級（扳手圖標）隊列設置中，有一個類似的選項可以增加目標隊列線程的數量。默認情況下，當您啓用目標隊列時，只有一個隊列線程處理FIFO序列中的消息。同樣，對消息順序很好，但會影響吞吐量。

如果做需要消息進行排序和希望最大化並行吞吐量（AKA有你魚與熊掌兼得的話），你可以在多個目標隊列中的線程一起使用線程分配變量。這允許您在具有相同唯一標識符的消息之間保持順序，而與不同標識符有關的消息可以同時處理。一個常見的用例是爲患者使用MRN，以便確保給定患者的所有信息按收到的順序處理，但縱向跨越不同患者的信息可以同時處理。