的BizTalk延遲增加1分鐘初始呼叫

的我跑在BizTalk Server 2016年業務流程，具有2路WCF接收端口（IIS）和SAP適配器發送端口，運行在SAP輕查詢。我正試圖優化性能。的BizTalk延遲增加1分鐘初始呼叫

我的問題是：當我把我的業務流程，第一次（我重新啓動主機實例後）第一次調用需要我的理解1秒左右是因爲它加載組件到內存中。隨後的通話速度更快，大約需要200-300 ms。但是，在第一次通話剛好1分鐘後，下一次通話再次需要1秒。該模式是：

1st call 1 s 
new call 300 ms 
new call 300 ms 
... 
new call 1 s (1 minute after the first call) 
new call 300 ms 
new call 300 ms 
...

這就像一些被從內存中1分鐘後清零，但我不明白爲什麼？我已經調整了配置文件，使組件從來沒有從內存中卸載，我有信息和業務流程的彙集降至50毫秒。

是否有任何其他的配置我需要改變嗎？

來源

2017-05-29 Andreof

的業務流程的AppDomain眼淚本身下來每過一段時間，如果它不活動。

如果你看看文檔here，有配置如何經常發生這種情況的選擇，特別是這部分似乎是你在找什麼：

在本節中，用戶可以指定defualt配置對於沒有與其關聯的命名配置的任何應用程序域（請參閱下面的AppDomainSpecs）

秒SecondEmptyBeforeShutdown是應用程序域在卸載之前爲空（即，它不包含任何編排）的秒數。指定-1表示應用程序域永遠不應該卸載，即使是空的。

同樣，SecondsIdleBeforeShutdown是幾秒鐘，一個應用程序域空閒（即，它僅包含脫水編排）被卸載前的數量。指定-1表示應用程序域在空閒但不爲空時不應該卸載。當一個空閒但非空的域被關閉時，所有包含的實例首先被脫水。

<DefaultSpec SecondsIdleBeforeShutdown="1200" SecondsEmptyBeforeShutdown="1800">

一定要小心，這真的應該徹底測試（特別是在一個時間至少測試它正常生產負荷下幾個小時）。它可能會在內存使用和整體性能方面產生其他不需要的副作用。在您的情況下，每秒付出的代價是否太高？

來源

2017-05-30 13:46:01

感謝您的答覆丹。我們正在嘗試創建一個低延遲主機來處理來自網站的請求。我已經完成了你提到的改變。但默認值是20分鐘，所以它不會對我們每60秒體驗到的內容負責。 – Andreof

啊，是的。我看得太快了。 –

60秒間隔好像的BizTalk緩存刷新具有由缺省此值的時間間隔。雖然它不會重新加載程序集和主要配置，但它實際上可能會在處理時間中添加小數位。
請參閱Configuration Cache Refresh Interval

來源

2017-05-31 09:25:30

謝謝Gediminas。我監視了哪些程序集正在加載，並且沒有新的加載。我認爲這是與BizTalk不得不重新壽命結束時的SQL連接相關。隨着跟蹤啓用，我可以看到，無論是編排和管道（在IIS中運行的軟件）花費比平時更長的時間（約500毫秒以上）。 – Andreof

的BizTalk延遲增加1分鐘初始呼叫

回答

相關問題